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1.  Introduction 


Chaosnet  is  a  local  network,  that  is,  a  system  for  communication  among  a  group  of 
computers  located  within  one  or  two  kilometers  of  each  other,  I  he  name  Chaosnet  refers  to  the 
lack  of  any  centralized  control  clement  in  this  network. 

Chaosnet  was  originally  developed  in  1975  by  the  Artificial  Intelligence  l  aboratory  of  die 
Massachusetts  Institute  of  Technology  as  the  internal  communications  medium  of  the  I  isp  Machine 
system  [CIIINUAI.,  AIM444).  It  has  since  come  to  be  used  to  link  a  variety  ol  machines  around 
the  Institute.  Chaosnets  also  exist  at  several  other  universities  and  research  laboratories. 

The  l  isp  Machine  system  is  a  multi  processor  in  which  each  active  user  is  assigned  a 
"personal"  computer  consisting  of  a  medium-scale  processor,  a  suitable  amount  of  memory,  and  a 
swapping  disk,  f  iles  arc  stored  in  a  central  file-system  accessed  through  Chaosnet,  fltis  shared 
file-system  retains  the  traditional  advantages  of  a  time-sharing  system,  munch,  inter-user 
communication,  shared  programs,  and  centralized  backup  and  maintenance.  At  the  same  time,  by 
giving  each  active  user  his  own  processor,  the  I  isp  Machine  system  is  much  more  capable  than  a 
time-sharing  system  at  executing  l  isp  programs  several  million  words  in  si/e  elliciently  and  with 
rapid  interactive  response,  because  Chaosnet  is  taking  the  place  of  the  file  disk  in  a  conventional 
system,  it  must  be  fast  (both  in  response  and  in  throughput),  it  must  Ik-  icliable  (th.s  is  the 
reason  why  there  is  no  centralized  control),  and  it  must  allow  connection  of  several  dozen 
machines.  However,  it  does  not  need  to  operate  over  long  distances.  Chaosnet  is  used  to  access 
other  shared  resources  itt  addition  to  the  file  system:  these  include  printeis.  tape  times,  and  one- 
of-a-kind  specialized  processors  and  I/O  devices. 

The  system  goals  for  Chaosnet  were  primarily  simplicity  and  high  performance.  The 
performance  is  achieved  by  starting  with  a  very  high  speed  transmission  medium  and  operating  it 
in  a  simple,  low-overhead  fashion,  rather  than  by  using  unusually  clever  algoiithms.  Of  course 
one  has  to  be  careful  to  avoid  algorithms  which  are  so  simple  that  they  don't  work  or  waste  so 
much  of  the  transmission  medium  that  performance  is  impacted.  Simplicity  was  important  not 
only  to  improve  performance,  but  because  Chaosnet  connects  a  diverse  set  ol  machines,  and 
hence  had  to  have  several  implementations  all  of  which  require  maintenance  in  propottioii  to  their 
complexity. 

Simplicity  of  design  also  aids  greatly  in  maintenance  and  management  of  the  network  itself, 
which  has  proven  to  be  a  non  trivial  task  in  a  network  involving  a  variety  ol  machines  and  used 
by  a  variety  of  groups,  even  within  the  single  institution  of  Mi  l.  It  is  important  to  be  able  to 
isolate  an  apparent  failure  of  the  whole  network  to  the  cubic  or  to  a  pm  duller  host's  h.mlwerc  or 
software  as  rapidly  as  possible. 

file  design  of  Chaosnet  was  greatly  simplilied  by  ignoring  problems  inclev.mt  to  local 
networks.  <  b  losnet  ioniums  no  special  provisions  for  things  such  as  low  speed  links,  noisy  (very 
high  error-rale)  links,  multiple  paths,  mul  lung  distance  links  with  sivmlii  ant  d.msit  tune.  Ibis 
means  that  Chaosnet  is  not  puiliculailv  suitable  for  use  ueioss  tin  tonimnu  oi  in  satellite 
applications.  (  hae'  in  t  also  makes  no  attempt  to  provide  unnece  mi\  femme-,  ir  b  as  multiple 
level  ,  o|  seivii  e  or  v  <  me  i ommiiuie.ilioii  (othei  than  bv  end  to  end  enuvptt<<n) 
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Chaosnet  was  largely  inspired  by  the  pioneering  work  on  local  networks  at  Xerox  PARC 
[ETHERNET], 

Chaosnet  consists  of  two  parts— the  hardware  and  the  software— which,  while  logically 
separable,  were  designed  for  each  other.  The  hardware  provides  a  carrier-sense  multiple-access 
structure  very  similar  to  the  PARC  Ethernet.  Network  nodes  contend  for  access  to  a  cable,  or 
ether,  over  which  they  may  transmit  packets  addressed  to  other  network  nodes.  The  software 
defines  higher-level  protocols  in  terms  of  packets.  These  protocols  can  be  (and  arc)  used  with 
media  other  than  tire  Chaosnet  cable,  and  with  multiple  interconnected  cables.  The  software 
contains  ideas  borrowed  from  Ethernet  (ETHERNET!,  TCP  (TCP],  and  Arpanet,  with  some 
original  ideas  and  modifications. 


lJSK:M(H)N;AMm:R  107 


.is  JUN-81 


Chaosnet 


3 


!  laidwaic  Protocol 


2.  Hardware  Protocol 

2.1  The  Ether 

The  transmission  medium  of  Chaosnet  is  called  the  ether.  Physically  it  is  a  coaxial  cable,  of 
the  semi-rigid  1/2  inch  low-loss  type  used  for  cable  TV,  with  75-ohm  termination  at  both  ends. 
At  each  network  node  a  cubic  transceiver  is  attached  to  the  cable.  A  10  meter  flat  cable  connects 
the  transceiver  to  an  interface  which  is  attached  to  a  computer's  I/O  bus.  A  network  node 
consists  of  this  transceiver  and  interface  and  a  computer  which  executes  a  certain  piece  of  software 
called  the  Network  Control  Program  (NCP),  which  manages  and  controls  Chaosnet,  in  addition  to 
whatever  application  software  justifies  its  existence  in  the  first  place. 

One  network  node  at  a  time  may  seize  the  ether  and  transmit  a  packet,  which  arrives  at  all 
other  nodes;  each  node  decides  in  hardware  whether  to  ignore  the  packet  or  to  receive  it.  A 
single  ether  must  be  a  linear  cable;  it  may  not  contain  branches  nor  stubs,  and  the  ends  may  not 
be  joined  into  a  circle.  The  maximum  length  of  an  ether  cable  is  about  1  kilometer.  This  is 
determined  by  dispersion  and  by  DC  attenuation.  The  maximum  number  of  nodes  on  a  single 
ether  is  probably  a  few  dozen.  This  is  determined  by  degradation  of  the  electrical  properties  of 
the  cable  by  the  connectors  used  to  attach  the  transceivers. 

The  maximum  length  of  an  ether  could  be  increased  by  using  repeaters  (bidirectional  digital 
amplifiers  joining  two  pieces  of  cable).  In  practice  this  is  not  done,  instead,  the  protocol 
provides  for  multiple  ethers,  joined  together  by  nodes  called  bridp.es  which  relay  packets  from  one 
ether  to  another.  A  bridge  is  typically  a  pdpll  computer  with  two  or  more  network  interfaces 
attached  to  it.  A  bridge  node  usually  performs  other  tasks  as  well,  such  as  interfacing  terminals. 
Bridges  attach  other  network  media  as  well  as  ethers;  some  computers  connect  to  the  network 
through  their  manufacturer's  high  speed  computcr-to-computcr  interface  to  a  nearby  bridge,  rather 
than  being  interfaced  directly  to  an  ether.  Asynchronous  lines  have  also  been  used  as  Chaosnet 
media. 

The  form  of  information  on  the  ether,  the  transceiver  and  interface  hardware,  and  the 
protocols  which  control  who  may  sci/.c  the  ether  arc  described  in  the  following  sections. 


2.2  Packets 

The  basic  unit  of  transmission  is  called  a  (racket.  This  is  a  sequence  of  up  to  4032  data  bits, 
plus  48  bits  of  hauler  information  used  by  the  hardware.  Backets  ms  are  normally  grouped  into 
16-hit  words.  The  division  of  a  transmitted  bit  stream  into  packets  provides  a  conveniently-sized 
unit  for  resource  allocation  and  error  control.  The  job  of  tire  hardware  is  to  deliver  a  packet 
from  one  node  to  another.  Software  protocols  define  the  meaning  of  the  data  bits  in  a  packet, 
manage  the  haulware,  compensate  for  imperfections  of  the  hardware,  and  pi  ovule  more  useful 
services  than  simple  transmission  of  packets  from  one  computer  to  another. 

The  hardware  header  consists  of  three  16  hit  words,  called  destination,  source ,  and  cheek. 

I  lie  source  identities  the  node  which  transmitted  ibis  packet  onto  this  ether  This  is  not 
nccessaiily  the  iriigin.il  sou  ire  of  the  message,  since  il  may  have  originated  on  a  different  ether. 
The  destination  identities  the  node  whi.  Ii  is  intended  to  receive  this  packet  (iom  tins  ether,  this 
is  not  ncces'-aiily  the  final  destination  of  the  message;  it  mav  be  a  bridge  which  should  relay  the 
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packet  to  another  ether,  whence  it  will  eventually  reach  its  final  destination,  The  check  word  is  a 
cyclic  redundancy  checksum,  generated  and  checked  by  hardware,  which  detects  errors  in 
transmission  through  the  ether,  cntircly-spurious  packets  created  by  noise  on  the  cable,  and 
memory  errors  in  the  transmitting  and  receiving  packet  buffers. 

The  software  protocol  is  also  based  on  packets,  taking  128  of  the  data  bits  as  a  software 
header.  This  is  described  in  section  3.5,  page  12. 

2.3  The  Transceiver 

Everyone  who  connects  to  the  ether  does  so  through  a  transceiver,  which  is  a  small  box 
which  mounts  directly  on  the  cable  via  a  UHF  connector  and  a  T-joint.  All  nodes  use  identical 
transceivers  (the  interface  varies  depending  on  what  computer  it  is  designed  to  interface  to).  ITie 
transceiver  contains  the  analog  portion  of  the  interface  logic,  provides  ground  isolation  between 
the  ether  cable  and  the  computer,  and  contains  some  protective  circuitry  designed  to  prevent  a 
malfunctioning  program  or  interface  from  continuously  jamming  the  ether.  (If  it  were  to  be 
redesigned,  it  ought  to  contain  even  more  protective  circuitry,  since  there  are  some  possible 
interface  failures  that  can  get  past  the  protection  and  render  the  ether  unusable.) 

The  transceiver  receives  a  differential  digital  signal  from  the  computer  interface  and  impresses 
it  onto  the  cable  as  a  level  of  about  8  volts  for  a  1,  or  0  volts  (open  circuit)  for  a  0,  through  a 
very  fast  VMOS  power  FIT.  When  the  cable  is  idle  it  is  held  at  0  volts  by  the  terminations, 
litis  simple-minded  unipolar  scheme  is  adequate  for  the  medium  cable  lengths  and  transmission 
speeds  we  arc  using.  The  transceiver  monitors  the  cable  by  comparing  it  against  a  reference 
voltage,  and  returns  a  differential  signal  to  the  interface.  In  addition,  it  detects  interference 
(another  transceiver  transmitting  at  the  same  time  as  this  one)  and  informs  the  interface. 

The  transceiver  includes  indicators  (light-emitting  diodes)  for  power  OK.  transmitted  data, 

received  data,  and  interface  attempting  to  jam  the  ether.  A  test  button  simulates  an  input  of 

continuous  l’s  from  the  interface,  which  should  light  all  the  lights  (dimly)  if  the  transceiver  is 
working.  These  indicators  and  the  test  button  are  useful  for  rapidly  tracking  down  network 
problems.  The  transceiver  requires  its  own  power  supply  mounted  nearby;  one  power  supply  can 
serv  ice  three  transceivers  if  they  arc  all  adjacent.  High-voltage  isolation  between  the  cable  and  the 
computer  is  provided  by  optical  isolators  within  the  transceiver. 

2.4  Tlie  Interface 

The  interface  is  typically  a  wire-wrap  board  containing  about  120  ITT.  logic  chips,  which 

plugs  into  the  I/O  bus  of  a  computer  and  connects  it  to  the  ether  (through  a  transceiver.)  The 

interlace  implements  the  hardware  protocols  described  in  the  next  section,  buffers  incoming  and 
outgoing  packets,  generates  and  checks  checksums,  and  interrupts  tlic  host  computer  when  a 
packet  is  to  be  read  out  of  the  receive  packet  buffer  or  stored  into  the  transmit  packet  buffer. 
These  packet  buffers  shield  the  host  computer  from  the  high  speed  of  data  transmission  on  tlic 
cable.  Instead  of  having  to  produce  bits  at  a  high  rale,  the  host  can  produce  them  at  a  lower 
rate,  collect  them  into  a  packet,  and  then  tell  the  interface  to  transmit  the  packet  in  a  single 
burst  of  high-speed  transmission. 
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Interfaces  currently  exist  for  Lisp  machines,  for  DHC  LSI-11  micro-computers,  and  for  the 
DKC  Unibus  [UN1BUS],  which  allows  Chaosnet  to  be  attached  to  pdpll’s,  VAX’s,  and  the 
peripheral  processors  of  most  pdplO’s.  Programming  documentation  for  this  compatible  family  of 
interfaces  appears  later  in  diis  paper. 

Interfaces  for  other  computers  are  likely  to  exist  in  the  future.  Hie  existing  interface  design 
docs  not  make  any  unusual  special  demands  of  its  host  computer  and  should  be  easily  adaptable 
to  other  architectures. 

2.5  Hardware  Protocols 

The  purpose  of  these  protocols  is  to  deliver  packets  intact  from  one  node  to  another  node  on 
the  same  ether,  with  fairly  high  probability  of  success,  and  to  guarantee  to  give  an  error 
indication  or  lose  the  packet  entirely  if  it  is  not  delivered  intact.  An  additional  purpose  is  to 
provide  high  performance  and  not  to  bog  down  when  subjected  to  a  heavy  load. 

Bits  are  represented  on  the  ether  using  a  technique  which  is  called  Upright  Biphase  NRZ1. 
Each  bit  cell,  which  is  approximately  250  nanoseconds  long,  begins  with  a  transition  in  state, 
from  high  to  low  or  from  low  to  high.  This  transition  marks  the  beginning  of  a  bit  cell  and 
provides  self-clocking.  3/4  of  the  way  through  the  bit  cell,  the  state  of  the  cable  is  sampled; 
high  represents  a  1  and  low  represents  a  0.  If  the  bit  being  represented  is  the  same  as  the 
previous  bit,  there  will  be  one  transition  at  the  beginning  of  the  bit  cell  and  a  second  in  the 
middle  of  the  bit  cell.  If  the  bit  being  represented  is  the  opposite  of  the  previous  bit,  there  will 
be  no  transition  in  the  middle  of  the  bit  cell  since  the  clock  transition  will  have  set  the  cable  to 
the  desired  suite.  The  AC  frequency  of  die  signal  on  the  cable  varies  between  1/2  the  bit  rate 
and  the  full  bit  rate.  The  information  bit-rate  is  4  million  bits  per  second. 

The  self-clocking  feature  allows  for  slight  variations  in  transmission  and  cable  propagation 
speed.  However,  since  die  3/4  of  a  bit  cell  delay  is  a  fixed  delay,  only  modest  variations  in 
speed  can  be  tolerated.  A  crystal  clock  is  used  as  die  source  of  die  transmit  timing  in  die 
interface. 

Since  there  is  always  at  least  one  state-transition  per  bit  cell,  the  suites  where  die  ether 
remains  high  or  low  for  an  appreciable  time  arc  available  for  non-data  uses.  If  the  ether  remains 
low  for  more  than  about  two  bit  cells,  it  is  considered  to  be  not-busy.  This  condition  marks  die 
end  of  a  packet  and  allows  someone  else  to  transmit.  Note  that  if  no  transceivers  are  active,  the 
terminations  will  hold  the  ether  low. 

If  the  ether  remains  high  for  about  two  bit  cells,  this  is  an  "abort  signal".  Abort  signals  are 
used  for  two  purposes.  If  the  transceiver  detects  a  collision  (two  nodes  trying  to  transmit  at  the 
same  time),  each  transmitting  interface  ceases  to  transmit  and  sends  an  aboil  signal  (four  bit  cells 
long),  which  tells  all  receivers  to  ignore  the  aborted  packet  and  ensures  that  the  oilici  transmitter 
also  aborts.  Thus  when  a  collision  occurs,  the  ether  is  cleared  as  soon  as  possible  to  help  prevent 
long  tie-ups  under  conditions  of  heavy  loud.  The  other  use  lor  the  abort  signal  is  in  hardware 
How-control.  When  a  icceiving  interface  deienuines  that  an  incoming  packet  is  addicssed  to  it, 
but  its  receive  buller  already  contains  a  p  icket,  it  sends  an  abort  signal  vvhi.  h  causes  die 
tiaiiMnilloi  lo  stop,  litis  saves  the  dual  pm  pose  of  immediately  informing  the  lianao  itei  i  hat  its 
messire  did  not  gel  tluoiiph.  and  prewnlmp  the  ether  from  being  lied  up  while  a  long,  packet  is 
Iran  ..milled  which  the  receiver  cannot  receive. 
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Packets  arc  transmitted  over  the  ether  in  reverse  bit-order,  for  hardware  convenience.  The 
three  header  words,  which  to  the  software  appear  to  be  at  the  end  of  the  packet,  arc  transmitted 
first  in  the  order  check,  source,  destination.  The  data  words,  in  reverse  order,  follow.  Words 
are  transmitted  least-significant  bit  first.  Of  course,  the  software  need  not  be  aware  of  this 
reversal;  packets  arrive  at  the  destination  in  the  same  form  as  they  were  created  by  the  source. 
At  the  end  of  the  packet,  an  extra  zero  bit  is  appended  to  bring  die  ether  to  the  low  state  so 
that  an  extra  spurious  clock-transition  will  not  be  generated  when  it  goes  idle.  This  bit  is  stripped 
oflf  by  the  interface  and  is  never  seen  by  software. 

The  check  word  is  used  for  error  detection,  as  described  above.  The  source  word  is  made 
available  to  die  software,  which  ignores  it  in  most  cases,  and  also  serves  to  synchronize  the  clocks 
in  the  collision-avoidance  mechanism  which  is  described  below.  1'he  destination  word  is  compared 
by  each  receiver  against  its  own  address.  If  they  match,  or  if  the  destination  is  zero,  or  if  the 
software  selects  the  "match  any  destination"  mode,  die  packet  is  placed  in  the  receive  packet 
buffer  and  the  host  computer  is  interrupted.  The  zero  destination  feature  is  used  for  "broadcast" 
messages.  Note  that  a  receiver  whose  packet  buffer  is  full  will  only  generate  an  abort  signal  if  the 
packet  was  specifically  addressed  to  it. 

2.6  Ether  Contention 

Chaosnet  has  no  centralized  control  element;  when  a  network  node  has  a  message  to  transmit, 
its  interface  seizes  the  ether  and  transmits  a  packet.  The  time  when  it  seizes  die  ether  is 
determined  only  by  state  inside  that  particular  interface  and  by  the  local  state  of  die  cable  at  the 
point  where  that  interface’s  transceiver  is  attached. 

If  two  interfaces  should  decide  to  seize  the  ether  and  transmit  at  the  same  time,  their 
transmissions  will  interfere  and  no  useful  information  will  be  transmitted.  This  is  called  a 
collision.  Collisions  arc  the  principal  limitation  on  the  bandwidth  of  a  heavily-loaded  ether-type 
network,  and  should  be  avoided.  (However,  ncidier  PARC's  network  nor  Mi  l’s  network  has  yet 
been  operated  with  a  heavy  enough  load  to  make  collisions  really  significant.) 

Chaosnet  uses  a  novel  collision  avoidance  technique.  First  of  all,  an  interface  will  never 
initiate  transmission  unless  the  ether  is  seen  to  he  not  busy,  i.e.  it  has  been  in  die  low  state  for 
some  time,  'this  ensures  that  collisions  can  only  occur  near  the  beginning  of  a  packet.  Once 
transmission  of  a  packet  has  gotten  well  started,  the  ether  is  effectively  "seized"  (all  interfaces 
realize  that  it  is  busy)  and  transmission  will  continue  successfully  through  to  die  end  of  the 

packet.  'I  he  amount  of  ether  transmission  time  wasted  by  a  collided  packet  is  therefore  limited  to 

the  round-trip  cable  propagation  delay.  This  technique  is  called  carrier  sense. 

Secondly,  the  hardware  uses  a  time-division  technique  to  attempt  to  prevent  two  inter  faces 
fmm  initiating  transmission  at  the  same  time.  This  technique  should  pieveiil  essentially  all 
collisions  while  imposing  only  a  modest  delay  in  the  initiation  of  transmission.  It  is  designed  so 
that  it  works  heller  as  the  load  on  the  ether  increases;  the  wasted  lime  between  packets  and  the 
relative  late  of  collisions  both  decrease. 

Ihc  basic  idea  is  lh.it  each  interface  is  assigned  a  time  slot,  or  Hon.  according  to  ils  address. 
Il  may  only  initiate  liansmission  dining  it-  turn.  I  lie  imu:  are  spa;  cd  far  ennugli  apart  that  if 

one  interlace  initiate-,  transmission,  every  other  inlcilace  will  perceive  that  die  dliei  >.  busy  hv  the 

time  its  ov  n  turn  ai lives,  and  will  not  initiate  .m  intci  lei  me  Iran mission  I'.uh  inn  iI.hc  contains 
,i  nme  slot  touni  i  which  munis  while  the  clhci  is  not  busy,  keeping  track  <>l  whose  turn  it  is. 
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Each  packet  synchronizes  the  counters  in  all  of  the  interfaces  by  setting  them  from  the  source 
address  of  that  packet;  at  the  time  the  packet  was  transmitted,  it  must  have  been  the  turn  of  the 
interface  that  transmitted  it. 

Another  way  to  think  of  this  is  to  make  an  analogy  with  ring  networks.  One  can  imagine  a 
virtual  token  which  passes  down  the  cable  until  it  gets  to  the  end,  then  jumps  to  the  beginning  of 
the  cable  and  repeats.  An  interface  may  only  initiate  transmission  at  the  instant  the  token  passes 
by  it.  When  an  interface  transmits,  the  token  stops  moving  and  remains  at  that  interface  until  the 
end  of  the  packet,  whereupon  it  continues  down  the  cable,  passing  every  other  interface,  giving 
them  each  a  chance  to  transmit  before  letting  the  first  interface  transmit  a  second  packet. 

The  token  is  not  represented  by  any  physical  transmission  on  the  cable.  That  would  constitute 
a  form  of  centralized  control,  and  would  lead  to  reliability  problems  if  the  token  was  lost  or 
duplicated.  Instead,  every  interface  contains  a  time-slot  counter  which  keeps  track  of  where  the 
token  is  thought  to  be.  Every  time  a  packet  is  transmitted  these  counters  arc  brought  up-to-date. 
The  token  cannot  be  lost  because  a  counter  by  its  nature  eventually  returns  to  all  previous  states. 
It  docs  not  matter  if  the  token  is  duplicated  (i.e.  the  counters  lose  synchronization)  occasionally, 
since  this  will  only  cause  collisions,  which  we  know  how  to  delect  and  deal  with,  and  since  the 
first  successful  transmission  will  resynchroni/.c  all  counters.  The  basic  mechanism  of  the  ether 
network  with  contention  and  collisions  is  known  to  work,  and  the  collision-avoidance  scheme  is  an 
added-on  optimization  which  improves  performance  without  changing  the  basic  mechanism. 

There  is  a  finite  propagation  delay  time  between  interfaces,  and  this  time  is  not  small 
compared  with  the  bit-rate  of  Chaosnet,  nor  when  compared  with  the  desirable  length  of  a  time 
slot.  This  time  consists  of  the  delay  in  the  cable,  about  5  nanoseconds  per  meter,  and  the  delay 
through  the  two  transceivers,  about  220  nanoseconds.  This  propagation  delay  means  tli.it  the  time¬ 
slot  counters  in  two  different  interfaces  cannot  be  exactly  synchronized,  and  that  when  interface  A 
initiates  transmission  interface  R  will  not  instantaneously  sec  that  the  ether  is  busy.  Special 
relativity  tells  us  that  in  fact  the  concept  "exactly  synchronized”  is  meaningless.  Since  the  tw'o 
time-slot  counters  arc  not  in  the  same  place,  the  only  way  we  can  compare  them  is  to  send  a 
message  from  one  to  the  other,  through  the  ether,  containing  the  reading  of  the  counter.  Rut  this 
message  takes  non-zero  time  to  get  there,  so  the  counter-reading  it  contains  is  wrong  by  the  lime 
it  is  compared  against  the  other  counter!  We  in  fact  do  send  messages  containing  counter 
readings;  die  source  address  in  a  packet  equals  the  reading  of  the  time-slot  counter  in  the 
interface  that  sent  it — at  the  time  it  was  sent.  Since  the  network  nodes  arc  not  in  relative  motion, 
we  can  measure  the  distance  between  them  and  use  that  information  to  improve  their 
synchronization. 

What  we  arc  trying  to  do  is  to  prevent  collisions.  This  n,\ms  that  if  interface  A  starts 
transmitting  a  packet  in  its  turn,  then  by  the  time  interface  R  thinks  that  its  own  turn  has  arrived, 

it  must  perceive  the  ether  as  busy.  We  will  assign  addresses  (and  hence  time  slots)  and  set  the 

length  of  <i  lime  slot  in  such  a  way  that  this  will  happen.  Suppose  the  maximum  delay  through 

the  ether  between  A  and  R  is  t.  This  would  be  the  delay  for  one  of  them  sending  a  packet  to 

the  other;  the  delay  between  A’s  receipt  of  a  third  party's  packet  and  It's  receipt  o!  that  packet  is 
less,  especially  if  the  third  party  is  between  A  and  R  on  the  cable  I  hen  the  maximum  perceived 
diHercncc  between  a  clock  at  A  and  a  clock  at  R  is  .?/:  it  a  message  is  sem  |m>iii  R  to  A 
synchronizin'.’,  the  clocks,  and  then  a  message  is  sent  from  A  to  It  containing  \\  clock  reading,  at 
It  this  clock  readme  will  be  slow  bv  .’/. 
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When  a  packet  transmitted  by  A  arrives  at  B,  B's  clock  may  read  as  much  as  2t  earlier  or 

later  than  A’s  turn,  depending  on  the  transmission  direction  of  the  last  synchronizing  message,  in 

order  to  guarantee  that  IVs  turn  has  not  yet  happened,  the  time  between  any  of  A’s  turns  and 

any  of  B’s  turns  must  always  be  at  least  2t ,  twice  the  maximum  propagation  delay  through  the 

ether  between  A  and  B.  This  is  the  important  idea!  We  cause  this  to  be  true  by  assigning 
addresses  starting  at  one  end  of  the  cable;  each  node’s  address  is  the  previous  node’s  address  plus 
twice  the  propagation  delay  between  them,  divided  by  the  length  of  a  turn.  It  is  easy  to  see  that 
if  this  is  done  for  all  adjacent  pairs,  the  condition  will  automatically  be  true  for  non-adjaccnt 
pairs  as  well.  When  we  get  to  the  end  of  the  cable,  we  must  assign  a  number  of  empty  slots 
equal  to  twice  the  propagation  delay  of  the  full  length  of  cable,  to  provide  the  necessary 
separation  between  the  turns  of  the  two  nodes  at  the  ends  of  the  cable. 

The  virtual  token  travels  through  the  network  at  a  substantially  slower  speed  than  a  real  signal 
such  as  a  packet;  in  the  fastest  case,  when  nodes  arc  very  far  apart,  it  travels  at  just  half  the 
speed  of  a  real  signal.  Since  a  Chaosnet  ether  has  the  geometry  of  a  line,  as  compared  to  the 
ring  net’s  circle,  the  virtual  token  is  also  slowed  down  by  the  need  to  return  from  the  end  of  the 
cable  to  die  beginning.  This  slower  speed  of  the  token  is  die  price  one  pays  for  the  increased 
robustness  of  Chaosnet  as  compared  with  a  ring  network.  In  a  real  system,  we  slow  the  token 
down  even  more  to  provide  a  margin  of  safety.  The  speed  of  the  network  is  not  significantly 
affected  by  die  slow  token,  since  the  interval  between  packet  transmissions  by  a  single  node  is 
much  longer  dian  the  round-trip  time  of  the  token.  Indeed,  if  the  network  is  being  used 
primarily  for  file  transfer,  and  hence  die  packets  are  large,  the  transmission  time  alone  for  a 
typical  packet  is  several  times  the  round-trip  time  of  the  token.  A  typical  value  for  the  token’s 
round-trip  time  is  64  microseconds. 

In  spite  of  all  this,  sometimes  collisions  will  occur  anyway.  If  the  cable  has  been  idle  for  a 
long  time,  the  various  clocks  will  have  lost  synchronization.  If  a  source  address  is  corrupted  by  a 
transmission  error,  any  interface  that  sees  that  source  address  will  set  its  clock  to  an  incorrect 
value.  Sometimes  a  packet  will  collide  with  random  noise  rather  than  another  legitimate  packet. 
In  addition,  the  transmitter  docs  not  distinguish  receiver-busy  aborts  from  real  collisions. 

When  a  collision  docs  occur,  we  recover  from  it  (in  software)  by  retransmitting  the  packet 
again  a  couple  of  times,  hoping  that  we  will  be  lucky  enough  not  to  have  another  collision,  or 
that  the  receiver  will  soon  clear  its  packet  buffer.  This  retransmission  is  done  by  the  software,  not 
the  hardware,  since  the  hardware  destroys  die  packet  in  its  packet  buffer  in  the  process  of 
transmitting  it.  But  if  collisions  continue  to  occur,  we  give  up  and  let  somebody  else  have  the 
ether.  Ihc  packet  is  lost.  A  higher  level  of  protocol  will  soon  realize  that  it  has  been  lost  and 
retransmit  it.  We  assume  that  there  is  enough  randomness  in  die  higher  level  software  that  the 
two  nodes  which  originally  collided  will  not  collide  again  on  the  retransmission  by  deciding  to 
retransmit  at  precisely  the  same  instant. 
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3.  Software  Protocol- World  View 

The  purpose  of  the  basic  software  protocol  of  Chaosnet  is  to  allow  high-speed  communication 
among  processes  on  different  machines,  with  no  undetected  transmission  errors.  The  speed  for  file 
transfers  in  real-life  circumstances  was  to  be  comparable  with  an  inexpensive  magnetic  tape  drive 
(30000  characters  per  second,  or  about  10  times  the  speed  of  the  Arpanet).  We  actually  get  about 
double  this  in  some  favorable  cases.  To  achieve  this  speed  it  was  important  to  design  out 
bottlenecks  such  as  arc  found  in  the  Arpanet,  for  instance  the  control-link  which  is  shared 
between  multiple  connections  and  the  need  to  acknowledge  each  message  before  the  next  message 
can  be  sent  The  protocol  must  be  simple,  for  the  sake  of  reliability  and  to  allow  its  use  by 
modest  computer  systems.  A  full  Chaosnet  Network  Control  Program  is  just  about  half  the  size 
of  an  Arpanet  NCP  on  the  same  machine,  and  the  protocol  allows  low-performance 
implementations  to  omit  some  features.  A  minimal  implementation  exists  for  a  single-chip 
microcomputer. 


3.1  Connections 

The  principal  service  provided  by  Chaosnet  is  a  connection  between  two  user  processes.  This 
is  a  full-duplex  reliable  packet-transmission  channel.  The  network  undertakes  never  to  garble, 
lose,  duplicate,  or  resequence  tine  packets;  in  the  event  of  a  serious  error  it  may  break  the 
connection  off  entirely,  informing  both  user  processes.  User  programs  may  ciihcr  deal  in  terms  of 
packets,  or  ignore  packet  boundaries  and  treat  the  connection  as  two  uni  directional  streams  of  8- 
bit  or  16-bit  bytes. 

On  top  of  the  connection  facility  "user"  programs  build  other  facilities,  such  as  file  access, 
interactive  terminal  connections,  and  data  in  other  byte  sizes,  such  as  36  bits.  The  meaning  of 
the  packets  or  bytes  transmitted  through  a  connection  is  defined  by  the  particular  higher-level 
protocol  in  use. 

In  addition  to  reliable  communication,  the  protocol  provides  flow  control,  includes  a  way  by 
which  prospective  communicants  may  get  in  touch  with  each  other  (called  contacting  or 
rendezvous),  and  provides  various  network  maintenance  and  housekeeping  facilities.  These  are 
discussed  later. 


3.2  Contact  Names 

When  fust  establishing  a  connection,  it  is  necessary  for  the  I  ui  communicating  processes  to 
contact  each  other.  In  addition,  in  the  usual  user/server  situation,  the  server  piocess  does  not 
exist  beforehand  and  needs  to  he  created  and  made  to  execute  the  appropriate  piugram. 

We  chose  to  implement  contacting  in  an  asymmetric  way.  (Once  the  connection  lias  been 
established  everything  is  completely  symmetiie.)  One  process  is  designated  the  user,  and  the  other 
is  designated  the  server,  flic  server  has  some  conten  t  name  to  which  ii  listens.  I  he  usei  process 
icquosls  its  local  operating  system  to  connect  it  to  the  sener.  spa  dying  the  netwoik  node  and 
contact  name  of  the  sener.  The  local  operating  system  semis  a  mev  ape  (a  st  for 

(  man  item)  to  the  i  mole  opeialmp  system,  which  examines  tin-  conu  t  name  and  creates  a 
connection  lo  a  lislcnmp  piocess.  clean  -,  a  mw  seiver  process  and  connects  to  it  oi  rejii  is  the 
icquest. 
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Automatically  discovering  to  which  host  to  connect  in  order  to  obtain  a  particular  service  is  a 
subject  for  higher-level  protocols  and  for  further  research.  It  is  not  dealt  with  by  Chaosnet. 

Once  a  connection  has  been  established,  there  is  no  more  need  for  the  contact  name  and  it  is 
discarded.  Indeed,  ollcn  the  contact  name  is  simply  the  name  of  a  service  (such  as  "TELNET") 
and  several  users  should  be  able  to  have  simultaneous  connections  to  separate  instances  of  that 
service,  so  contact  names  must  be  reusable. 

In  the  ease  where  two  existing  processes  that  already  know  about  each  other  want  to  establish 
a  connection,  we  arbitrarily  designate  one  as  the  listener  (server)  and  the  other  as  the  requester 
(user).  The  listener  somehow  generates  a  "unique"  contact  name,  somehow  communicates  it  to 
the  requester,  and  listens  for  it.  'ITic  requester  requests  to  connect  to  that  contact  name  and  the 
connection  is  established.  In  the  most  common  ease  of  establishing  a  second  connection  between 
two  processes  which  arc  already  connected,  the  index  number  (see  below)  of  the  first  connection 
can  serve  as  a  unique  contact  name. 

Contact  names  arc  restricted  to  strings  of  upper-ease  letters,  numbers,  and  ASCII  punctuation. 
The  maximum  length  of  a  contact  name  is  limited  only  by  the  packet  size,  although  on  ITS  hosts 
the  names  of  automatically-started  servers  arc  limited  by  the  file-system  to  six  characters. 

See  page  21  for  complete  details  of  how  to  establish  a  connection. 

3.3  Addresses  and  Indices 

l;.ach  node  (or  host)  on  the  network  is  identified  by  an  address ,  which  is  a  16-bit  number. 
'These  addresses  are  used  in  the  routing  of  packets.  There  is  a  table  (the  system  hosts  table, 
SYSfl IN ; HOSTS 2,  in  the  ease  of  ITS)  which  relates  symbolic  host  names  to  numeric  host 
addresses. 

An  address  consists  of  two  fields.  The  most-significant  8  bits  identify  a  subnet,  and  the  least- 
significant  8  bits  identify  a  host  within  that  subnet.  Both  fields  must  be  non-zero.  A  subnet 
corresponds  to  a  single  transmission  path.  Some  subnets  are  physical  Chaosnet  cables  (ethers), 
while  others  are  other  media,  for  instance  an  interface  between  a  pdplO  and  a  pdpll.  The 
significance  of  subnets  will  become  clear  when  routing  is  discussed  (sec  section  3.7,  page  13). 

When  a  host  is  connected  to  an  ether,  the  host’s  hardware  address  on  that  ether  is  the  same 
as  its  soflwaie  address,  including  the  subnet  field. 

A  connection  is  specified  by  the  names  of  its  two  ends.  Such  a  name  consists  of  a  16-hit  host 
addiess  and  a  In-hit  connection  index,  which  is  assigned  h>  that  host,  as  the  name  of  the  entity 
niMde  the  host  which  owns  the  connection.  Ihc  only  requirements  placed  In  (I i< -  pioiocol  on 
indices  aie  that  they  he  non  zero  and  that  they  he  unique  within  a  partuiilai  ho.t;  that  is,  a  host 
may  not  a  .-igti  the  same  index  number  to  two  dillcrciii  i  ounce t ions  unless  cnoir  h  time  has 
1  lap'cd  between  the  closing  ol  the  liisl  connection  and  the  opening  ol  the  vsoiid  connection  that 
contusion  between  Ihc  two  is  unlikely. 


I  -  pic., IT,  (In  Ic.r 
.  .n  to  ,  i  M,  til. I  i 
••  |  l"  !  !c  unng:  in  ■ 
.a  a  h  i  i-'  in- 


- 1;  inlicinl  n  Inis  ol  an  index  are  trod  as  a  si'h'iiipi  n  to  the  epci  it  me 

c  iin i- 1  ■  i'  nil  i  Mil  In  n  hits  a. c  in,  | ,  ni,  nli  d  i.  h  t"Oi  .1  i  r  lc  l..|  i  c  u  i  . I. 

I  h'1  imuil'ci  ol  1 1 "  t  |i  1 1  c  n  i  Ini  i  i 1 1 1  i  ' '  .Uni. nil,  I  .  .  .  n.pu,  I  1. 1  |lu- 

.’!»  I  ihlc  sill.  II  ■  Kill’ll.  l'i  It  I!  I  . . til',:  ho. .  1 1 : .  ■  .  mi.  nn|,-.  .1 
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packet  from  the  old  connection  cannot  sit  around  in  the  network  (e.g.  in  buffers  inside  hosts  or 
bridges)  long  enough  to  be  seen  as  belonging  to  the  new  connection. 

It  is  important  to  note  that  packets  arc  not  sent  betv  •■cn  hosts  (physical  computers).  They  are 
sent  between  user  processes;  more  exactly,  between  channels  attached  to  user  processes.  Each 
channel  has  a  32-hit  identification,  which  is  divided  into  subnet,  host,  index,  and  imiquization 
fields.  From  the  point  of  a  view  of  a  user  process  using  the  network,  the  Network  Control 
Program  section  of  his  host’s  operating  system  is  part  of  the  network,  and  the  multiplexing  and 
demultiplexing  it  performs  is  no  different  from  the  routing  performed  by  other  parts  of  the 
network.  It  makes  no  difference  whether  two  communicating  processes  run  in  the  same  host  or  in 
different  hosts. 

Certain  control  packets,  however,  arc  sent  between  hosts  rather  than  users.  This  is  visible  to 
users  when  opening  a  connection;  a  contact  name  is  only  valid  with  respect  to  a  particular  host. 
This  is  a  compromise  in  the  design  of  Chaosnet,  which  was  made  so  that  an  operational  system 
could  be  built  without  first  solving  the  research  and  engineering  problems  associated  with  making 
a  diverse  set  of  hosts  into  a  uniform,  one-level  name  space. 

3.4  Packet  Numbers 

There  arc  two  kinds  of  packets,  controlled  and  uncontrolled.  Controlled  packets  are  subject  to 
error-control  and  flow-control  protocols,  described  below  (see  section  3.8,  page  16),  which 
guarantee  that  each  controlled  packet  is  delivered  to  its  destination  exactly  once,  that  the 
controlled  packets  belonging  to  a  single  connection  are  delivered  in  the  same  order  they  were  sent, 
and  that  a  slow  receiver  is  not  overwhelmed  with  packets  from  a  fast  sender.  Uncontrolled 
packets  arc  simply  transmitted;  they  will  usually  but  not  always  arrive  at  their  destination  exactly 
once.  The  protocol  for  using  them  must  take  this  into  account. 

Each  controlled  packet  is  identified  by  an  unsigned  16-bit  packet  number.  Successive  packets 
arc  identified  by  sequential  numbers,  with  wrap-around  from  all  I’s  to  all  0's.  When  a  connection 
is  first  opened,  each  end  numbers  its  first  controlled  packet  (RFC  or  OPN)  however  it  likes,  and 
that  sets  the  numbering  for  all  following  packets. 

Packet  numbers  should  be  compared  modulo  65536  (2  to  the  16th),  to  ensure  correct  handling 
of  wrap-around  cases.  On  a  pdpll,  use  the  instructions 
CMP  A , B 
BMI  A_is_less 

Do  not  use  the  BUT  or  BLO  instruction.  On  a  pdplO,  use  the  inst.  chons 
SIJB  A ,  B 
TUNE  A, 100000 
JHST  A_is_less 

Do  not  use  the  CAMC.I  instruction.  On  a  l  isp  machine,  use  the  code 
(II  (BN  ITS !  tin  100000  (  A  B)  ) 

-A  is  Irss>) 

Do  not  use  the  I  I  S3P  (or  <)  function. 
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3.5  Packets 

A  packet  consists  of  a  header,  which  is  8  16-bit  words,  and  zero  or  more  8-bit  or  16-bit  bytes 

of  accompanying  data.  In  addition  there  are  three  words  put  on  by  the  hardware,  described 

earlier  in  this  paper. 

The  following  arc  the  8  header  words: 

Operation  The  most-significant  8  bits  of  this  word  arc  the  Opcode  of  the  packet,  a 

number  which  tells  what  the  packet  means.  The  128  opcodes  with  high-order 

bit  0  arc  for  the  use  of  the  network  itself.  The  128  opcodes  with  high-order 

bit  1  are  for  use  by  users.  'ITte  various  opcodes  arc  described  in  chapter  4, 
page  20. 

The  least-significant  8  bits  of  this  word  are  reserved  for  future  use,  and  must 
be  zero. 

Count  The  most-significant  4  bits  of  this  word  arc  the  forwarding  count,  which  tells 

how  many  times  this  packet  has  been  forwarded  by  bridges.  Its  use  is 
explained  in  the  Routing  section. 

The  least-significant  12  bits  of  this  word  arc  the  data  byte  count,  which  tells 
the  number  of  8-bit  bytes  of  data  in  the  packet.  The  minimum  value  is  0  and 
the  maximum  value  is  488.  Note  that  the  count  is  in  8-bit  bytes  even  if  the 
data  arc  regarded  as  16-bit  bytes. 

Destination  Address 

This  word  contains  the  network  address  of  the  destination  host  to  which  this 
packet  should  be  sent. 

Destination  Index  This  word  contains  the  connection  index  at  the  destination  host  of  the 
connection  to  which  this  packet  belongs,  or  0  if  this  packet  docs  not  belong  to 
any  connection. 

Source  Address  This  word  contains  the  network  address  of  the  source  host  which  originated  this 
packet. 

Source  Index  This  word  contains  the  connection  index  at  the  source  host  of  the  connection 
to  which  this  packet  belongs,  or  0  if  this  packet  does  not  belong  to  any 
connection. 

racket  Number  If  this  is  a  controlled  packet,  this  word  contains  its  identifying  number. 

Acknowledgement  The  use  of  this  word  is  described  in  section  .1.8,  p.igc  16. 
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3.6  Data  Formats 

Data  transmitted  through  Chaosnet  generally  follow  [  isp  Machine  standards,  hits  and  bytes 
arc  numbered  from  right  to  left,  or  least-significant  to  most-significant.  The  first  8  bit  byte  in  a 
16-bit  word  is  the  one  in  the  arithmetically  least-significant  position.  The  first-  16  bit  word  in  a 
32-bit  double-word  is  the  one  in  the  arithmetically  least-significant  position. 

The  character  set  used  is  dictated  by  the  higher-level  protocol  in  use.  Telnet  and  Supdup,  for 
example,  each  specifies  its  own  ASCII-based  character  set.  The  "default"  character  set— used  for 
new  protocols  and  for  text  that  appears  in  the  basic  Chaosnet  protocol,  such  as  contact  names — is 
die  l  isp  Machine  character  set  [ClIINUAI.].  This  is  basically  ASCII,  augmented  with  additional 
printing  characters  and  a  different  set  of  format-cffcctor  (or  "control")  characters. 

Because  the  rules  for  bit  numbering  conflict  with  the  native  byte-ordering  in  pdplOs,  and 
because  it  is  quite  expensive  to  rearrange  die  bytes  using  the  pdplO  instruction  set.  pdplls  which 
act  as  front-ends  for  pdplOs  must  reformat  packets  passing  through  them,  and  pdplOs  interfaced 
directly  to  the  network  must  have  interfaces  capable  of  rearranging  the  bytes.  This  requires  that 
die  network  protocols  explicitly  specify  which  portions  of  each  type  of  packet  are  8-bit  bytes  and 
which  are  16-bit  bytes.  In  genera!  the  header  is  16-bit  bytes  and  the  data  field  is  8-bit  bytes,  but 
certain  packet  types  (Ol’N,  SIS,  BUT.  and  opcodes  300  through  377)  have  16-bit  bytes  in  die 
data  field.  Use  of  32-bit  data  is  rare,  so  no  provision  is  made  for  putting  32-bit  data  into  the 
standard  format  for  pdplOs.  On  our  current  network  pdplOs  arc  the  only  hosts  which  require  this 
packet  reformatting  assistance,  because  most  modern  computers  number  their  bits  and  bytes  from 
least-significant  to  most-significant. 

The  effect  of  this  is  diat  user  programs  that  use  the  Chaosnet  always  sec  the  data  in  a  packet 
and  its  header  in  the  native  form  of  the  machine  they  arc  running  on.  and  the  necessary 
conversions  are  automatically  applied  by  the  network.  This  statement  applies  to  die  order  of  bits 
and  bytes  within  a  word,  but  not  to  the  character  set  (when  packets  contain  textual  data)  which  is 
dictated  by  protocols. 

Unlike  some  other  network  protocols,  Chaosnet  does  not  use  any  software  checksumming. 
Because  of  the  diversity  of  hosts  with  different  architectures  attached  to  the  Chaosnet,  it  is 
impossible  to  devise  a  checksumming  algorithm  which  can  be  executed  compatibly  and  efficiently 
on  all  hosts.  Instead,  Chaosnet  relics  on  error-checking  hardware  in  die  network  interfaces,  and 
assumes  that  other  sources  of  packet  damage  that  checksums  could  detect,  such  as  software  bugs 
in  a  Network  Control  Program,  either  do  not  occur  or  will  produce  symptoms  so  olnious  that 
they  will  be  detected  and  fixed  immediately. 


3.7  Routing 

Hoiilinft  consists  of  deciding  how  to  deliver  a  packet  to  the  nciwoik  node  specified  by  die 
destination  address  field  of  the  packet.  Having  reached  that  node,  the  p.ukel  tan  trivially  be 
delivered  to  the  destination  user  process  via  (lie  destination  index,  hi  genet. il  muling  may  be  a 
ii  it  ill  i  step  ptoeess  involving  transmission  lliinugh  several  subnets,  stme  ilieie  mav  not  lie  a  din'd 
hardware  connection  between  the  somce  uni  the  destination.  Note  that  the  lontnig  .Ueision  is 
made  sepaiaie/y  tor  tael  i  packet,  nit  It  no  t  <  lenm  e  to  (be  epl  o  I  u>iiim  lions. 
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Any  host  that  is  connected  to  more  than  one  subnet  acts  as  a  bridge  and  forwards  packets 
from  one  subnet  to  another  when  necessary.  There  could  also  be  hardware  bridges  which  are  not 
hosts,  although  we  have  not  yet  designed  any  such  device.  Since  routing  docs  not  depend  on 
connections,  a  bridge  is  a  very  simple  device  (or  program)  which  does  not  need  much  state.  This 
makes  the  bridge  function  inexpensive  to  piggyback  onto  a  computer  which  is  also  performing 
other  functions,  and  makes  reliable  bridge  software  easy  to  implement. 

The  difference  between  a  bridge  and  a  gateway,  in  our  terminology,  is  that  a  bridge  forwards 
packets  from  one  sub-Chaosnet  to  another,  without  modifying  the  packets  or  understanding  them 
other  than  to  look  at  the  destination  address  and  increment  die  forwarding  count,  and  does  not 
deal  with  connections  nor  widi  flow  control,  while  a  gateway  interconnects  two  networks  with 
differing  protocols  and  must  understand  and  translate  die  information  passing  through  it 
Gateways  may  also  have  to  deal  with  flow  and  error  control  because  they  connect  networks  with 
slow  or  differing  speeds.  Bridges  are  suitable  for  local  networks  while  gateways  arc  suitable  for 
long-distance  networks  and  for  connecting  networks  not  produced  by  the  same  organization. 

To  prevent  routing  loops,  each  packet  contains  a  forwarding-count  field.  Kach  bridge  that 
forwards  the  packet  increments  this  count;  if  the  count  reaches  its  maximum  value  the  packet  is 
discarded.  The  error-control  protocol  will  recover  discarded  packets,  or  decide  diat  no  viable 
connection  can  be  established  between  the  two  hosts. 

The  implementation  of  routing  in  an  operating  system  is  as  follows,  given  a  packet  to  be 
routed,  which  may  have  come  in  from  die  network  or  may  have  been  originated  by  the  local 
host,  first,  check  the  packet’s  destination  address.  If  it  is  this  host,  receive  the  packet. 
Otherwise,  increment  the  forwarding  count  and  discard  the  packet  if  it  has  been  forwarded  too 
many  times,  if  the  destination  is  some  other  host  on  a  subnet  to  which  this  host  is  directly 
connected,  transmit  die  packet  on  that  subnet;  the  destination  host  should  receive  it.  If  the 
destination  is  a  host  on  a  subnet  of  which  this  host  has  no  knowledge,  look  up  the  subnet  in  the 
host's  routing  table  to  find  the  best  bridge  to  that  subnet,  and  transmit  the  packet  to  diat  bridge. 

Fiach  host  has  a  routing  table,  indexed  by  subnet  number,  which  tells  how  to  get  packets  to 
hosts  on  diat  subnet.  Kach  entry  contains:  (exact  details  may  vary  depending  on  implementation) 

Type  The  type  of  connection  between  the  host  and  this  subnet.  This  can  be  one  of 

Direct,  Bridge,  or  fixed  Bridge.  Direct  means  a  physical  connection  such  as  a 
Chaosnet  interface.  Bridge  means  an  indirect  connection,  via  a  packet-forwarding 
bridge.  Which  bridge  is  best  to  use  is  to  be  discovered  by  this  routing 
mechanism,  fixed  Bridge  is  the  same  except  that  the  automatic  mechanism  is  not 
to  change  which  bridge  is  used.  This  is  useful  to  set  up  explicit  touting  for 
purposes  such  as  network  debugging. 

Idihess  Identifies  the  tonnectiou  to  this  subnet  in  a  way  wliiih  depends  on  the  type,  l  or 

a  duel  l  connection,  this  identities  the  piece  of  hardware  which  implements  the 
connection.  (It  might  fie  a  l  Inibus  address.)  for  a  btidge  or  a  fixed  bridge,  this 
is  the  network  address  of  the  bridge. 

(  os t  A  measure  of  the  cost  of  sending  a  packet  tliiough  this  mute.  Costs  are  used  to 

si  ted  the  best  route  from  among  altei natives  in  .1  way  desciibed  below,  for  a 
direct  connection  tin-  cost  is  III  for  a  dmst  inlet  lace  between  two  computers  (eg. 
b'  lwien  a  pdplt)  and  m  lioni-einl  pdpli).  II  loi  a  (  haouid  edict  c.ihle.  i'll  lot 
.1  slow  medium  si n  li  as  in  asynchronous  hue,  etc.  l  or  a  budge  or  a  lived  btidge. 
tin  co- 1  is  spe  died  h>  the  biidge  in  a  ft  I  puked  (desciibed  below). 
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The  routing  tabic  is  initialized  with  the  number  of  a  more  or  less  arbitrary  existent  host  and  a 
high  cost,  for  each  subnet  to  which  the  host  is  not  directly  connected.  Until  the  correct  bridge  is 
discovered  (which  normally  happens  within  a  minute  of  coming  up),  packets  for  that  subnet  will 
be  bounced  oft'  of  that  arbitrary  host,  which  probably  knows  the  right  bridge  to  forward  them  to. 

The  cost  for  subnets  accessed  via  bridges  is  increased  by  1  every  4  seconds,  thus  typically 
doubling  after  a  minute.  When  the  cost  reaches  a  "high"  value,  it  sticks  there,  preventing 
problems  with  arithmetic  overflow.  The  purpose  of  the  increasing  cost  is  to  discount  the  value  of 
old  information.  Ihc  cost  for  subnets  accessed  via  direct  connections  and  fixed  bridges  docs  not 
increase. 

Every  15  seconds,  a  bridge  advertises  its  presence  by  broadcasting  a  routing  (RUT)  packet  on 
each  subnet  to  which  it  is  directly  connected.  Each  host  on  that  subnet  receives  the  RUT  packet 
and  uses  it  to  update  its  routing  table.  If  die  host’s  routing  table  says  to  access  a  certain  subnet 
via  bridges,  and  the  RUl  packet  says  that  diis  is  the  best  bridge  to  that  subnet,  the  routing  table 
is  updated  to  say  that  this  bridge  should  be  used. 

Note  that  it  is  important  that  the  rate  at  which  the  costs  increase  with  time  be  slow  enough 
that  it  takes  more  than  twice  die  broadcast  interval  to  increase  the  cost  of  one  hop  to  be  more 
than  the  cost  of  two  hops.  Otherwise  the  routing  algorithm  is  not  well-behaved.  Suppose  subnet 
A  has  two  bridges  (»»  and  p)  on  it,  and  bridge  a  is  connected  to  subnet  B  but  bridge  p  is  not  (it 
goes  to  some  other  irrelevant  subnet).  Then  if  the  costs  increase  too  fast  and  bridges  «  and  p  do 
not  broadcast  their  RUT  packets  exactly  simultaneously,  sometimes  packets  for  subnet  B  may  be 
sent  to  bridge  p  because  its  cost  appears  lower.  Bridge  p  will  then  send  diem  to  bridge  a,  where 
they  should  have  gone  directly.  In  more  complicated  situations  packets  can  go  around  in  a  circle 
some  of  the  time. 

The  source  address  of  a  RUl'  packet  must  be  die  hardware  address  of  die  bridge  on  the 
particular  subnet  on  which  die  packet  is  broadcast.  The  destination  address  of  a  RUT  packet 
must  be  zero;  RUT  packets  arc  not  forwarded  onto  other  subnets.  Ihc  byte  count  of  a  RU  T 
packet  is  a  multiple  of  4  and  the  packet  contains  up  to  122  pairs  of  16-bit  words; 

word  1  The  subnet  number  of  a  subnet  which  this  bridge  can  get  to.  directly  or 

indirectly,  right-adjusted. 

word  2  Hie  cost  of  sending  to  that  subnet  via  this  bridge.  This  is  the  current  cost  from 

the  bridge’s  routing  table,  plus  the  cost  for  the  subnet  on  which  the  routing 
packet  is  being  broadcast.  Adding  the  subnet  cost  eliminates  loops,  and  prefers 
one-hop  paths  over  two-bop  padis. 

When  a  host  receives  a  RUT  packet,  it  processes  each  2-word  entry  by  comparing  the  cost  for 
that  subnet  against  its  current  cost;  if  it  is  less  or  equal  the  cost  and  the  address  of  the  biidgc 
arc  entered  into  the  routing  table,  provided  that  that  subnet’s  routing  table  entry  is  not  of  the 
Direct  or  f  ixed  Bridge  type. 

When  there  are  multiple  equivalent  bridges,  Ihc  traflic  is  spread  among  them  only  by  virtue 
of  their  RUT  packets  being  sent  at  diflerent  times,  so  that  sometimes  one  bridge  lias  ihc  lower 
cost,  and  sometimes  the  oilier.  If  this  isn't  adequate,  hosts  could  have  luiiiei  in, mug  tables 
which  lemembei  mote  dun  one  possible  ionic  and  use  ihem  aceonliug  in  then  lelative  i  lists,  but 
so  I, ii  this  has  mu  been  neees'  ,ry  mikv  the  nuwoik  trallie  is  m  l  so  lugli  as  to  s.am  iie  any  one 
bridge. 
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The  design  of  this  routing  scheme  is  predicated  on  the  assumption  that  the  network  geometry 
is  simple,  there  arc  few  multiple  paths,  and  the  length  of  any  path  is  quite  short,  lhis  makes 
more  sophisticated  schemes  unnecessary. 

An  important  feature  of  this  routing  scheme  is  that  the  size  of  the  table  is  proportional -to  the 
number  of  subnets,  not  to  the  number  of  hosts.  Thus  it  docs  not  take  up  an  inordinate  amount 
of  memory  in  a  small  computer,  and  no  complicated  dynamic  allocation  schemes  arc  required. 

In  the  case  of  a  pdplO  which  accesses  the  Chaosnet  through  a  front-end  pdpll,  we  define  the 
interface  between  the  two  computers  to  be  a  subnet,  and  regard  the  pdpll  as  a  bridge  which 
forwards  packets  between  the  network  and  the  pdplO.  This  gives  the  pdplO  and  the  pdpll 
separate  addresses  so  that  we  can  choose  to  talk  to  either  one,  even  though  they  arc  part  of  the 
same  computer  system.  This  is  occasionally  useful  for  maintenance  purposes.  It  becomes  more 
useful  when  the  front-end  pdpll  has  peripherals  which  arc  to  be  accessed  through  the  Chaosnet, 
since  they  can  simply  look  like  hosts  on  that  pdpll’s  private  subnet. 

In  the  case  of  a  host  which  is  attached  to  more  than  one  subnet,  it  is  undesirable  for  the  host 
to  have  more  than  one  address,  since  this  would  complicate  user  programs  which  use  addresses. 
Instead,  one  of  the  host’s  network  attachments  is  designated  as  primary,  and  that  address  is  used 
as  the  host’s  single  address.  The  other  attachments  are  regarded  as  bridges  which  can  forward  to 
that  host.  Sometimes,  we  simplify  the  routing  by  inventing  a  new  subnet  which  contains  only  that 
host  and  has  no  physical  realization.  The  host’s  address  is  an  address  on  that  fake  subnet.  All  of 
the  host’s  network  attachments  are  regarded  as  bridges  which  know  how  to  forward  packets  to  that 
subnet. 

The  ITS  host  table  allows  a  host  to  have  multiple  addresses  on  multiple  networks,  but  when 
you  ask  for  the  address  of  a  certain  host  on  a  certain  network  you  only  get  back  the  primary 
address.  All  packets  coming  from  that  host  have  that  as  their  source  address. 

3.8  Flow  and  Error  Control 

The  Network  Control  Programs  (NCPs)  conspire  to  ensure  that  data  packets  arc  sent  from 
user  to  user  with  no  garbling,  duplications,  omissions,  or  changes  of  order.  Secondarily,  the 
NCPs  attempt  to  achieve  a  maximum  rate  of  flow  of  data,  and  a  minimum  of  overhead  and 
retransmission. 

The  fundamental  basis  of  flow-control  and  error-control  in  Chaosnet  is  retransmission.  Packets 
winch  are  damaged  in  tiansmission,  which  won’t  fit  in  buffers,  which  are  duplicated  or  out-of- 
sequcncc,  or  which  otherwise  arc  embarrassing  are  simply  discarded.  Packets  are  periodically 
retransmitted  until  an  indication  that  they  have  been  successfully  received  is  returned.  Ibis 
retransmission  is  cnd-lo-cnd;  any  intermediate  bridges  do  not  participate  in  How-control  and  error- 
control.  and  hence  arc  free  to  discard  any  packets  they  wish. 

There  are  actually  two  kinds  of  packets,  coniroflnf  and  uncontrolled.  Controlled  packets  arc 
iciraiismiHal  and  delivered  reliably;  most  packets,  including  all  packets  used  by  the  user  (except 
for  I  INC  packets),  are  of  this  type.  Uncontrolled  pm  kets  are  not  ivlran '.milled;  these  arc  used 
fin  i.eit.iiii  lower- level  functions  of  the  protocol  such  as  the  implementation  of  (low  and  error 
control.  I  lie  usage  of  these  packets  is  designed  so  that  they  need  not  he  cMivcicd  rch  ihly. 
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Retransmission  of  a  packet  continues  until  stopped  by  a  signal  from  the  receiver  to  [jic  sender 
called  a  receipt.  A  receipt  contains  a  packet  number,  and  indicates  that  all  controlled  packets  with 
a  packet  number  less  than  or  equal  (modulo  65536)  to  that  number  have  been  successfully 
received,  and  therefore  need  not  be  retransmitted  any  more.  A  receipt  docs  not  indicate  that 
these  packets  have  been  processed  by  the  destination  user  process;  it  simply  indicates  that  they 
have  successfully  arrived  in  the  destination  host,  and  arc  guaranteed  to  be  there  when  the  user 
process  asks  for  them. 

There  is  another  signal  from  the  receiver  to  the  sender,  called  an  acknowledgement.  An 
acknowledgement  also  contains  a  packet  number,  and  indicates  that  all  controlled  packets  with  a 
packet  number  less  than  or  equal  (modulo  65536)  to  that  number  have  been  read  by  the 
destination  user  process.  1'his  is  used  to  implement  flow-control.  Note  Uiat  acknowledgement  of  a 
packet  implies  receipt  of  that  packet.  In  fact,  if  the  receiving  process  does  not  fall  behind, 
explicit  receipts  need  not  be  sent,  because  the  receiving  host  will  not  have  to  buffer  any  packets, 
but  will  acknowledge  diem  as  soon  as  they  arrive. 

The  purpose  of  flow-control  is  to  match  the  speeds  of  the  sending  and  receiving  processes. 
The  extremes  to  be  avoided  are,  on  die  one  hand,  too  small  a  "buffer  size"  causing  the  data 
transmission  rate  to  be  slower  than  it  could  be,  and  on  the  other  hand,  large  numbers  of  packets 
piling  up  in  the  network  because  the  sender  is  sending  faster  than  the  receiver  is  receiving.  It  is 
also  necessary  to  be  aware  dial  receipts  and  acknowledgements  must  be  transmitted  through  die 
network,  and  hence  have  an  associated  cost. 


Chaosnet  flow-control  operates  by  controlling  the  number  of  packets  "in  the  network".  These 
are  packets  which  have  been  emitted  by  the  sending  user  process,  but  have  not  been 
acknowledged.  We  define  a  window  into  the  set  of  packet  numbers.  The  beginning  of  this 
window  is  the  first  packet  number  which  has  not  been  acknowledged,  and  die  width  of  the 
window  is  a  fixed  number  established  when  the  connection  is  opened.  The  sending  process  is 
only  allowed  to  emit  packets  whose  packet  numbers  lie  within  the  window.  Once  it  has  emitted 
all  of  the  packets  in  the  window,  die  window  is  said  to  be  full.  Thus,  die  size  of  die  window  is 
the  "buffer  size"  for  the  connection,  and  is  the  maximum  number  of  packets  that  may  need  to  be 
buffered  inside  an  NCR  (sending  or  receiving).  Acknowledgements  move  die  window,  making  it 
not  full,  and  allowing  the  sending  process  to  emit  additional  packets. 

We  do  not  receipt  and  acknowledge  every  single  controlled  packet  that  is  transmitted  through 
a  connection,  since  that  would  double  or  triple  die  number  of  packets  sent  through  the  network 
to  move  a  given  amount  of  data.  Instead  we  batch  the  receipts  and  acknowledgements.  But  if 
acknowledgements  are  not  sent  sufficiently  often,  the  data  will  not  flow  smoothly,  because  the 
window  will  often  appear  full  to  the  sender  when  it  is  not.  If  receipts  are  not  sent  sufficiently 
often,  there  will  be  unnecessary  retransmissions. 

Whenever  a  packet  is  sent  through  a  connection,  an  acknowledgement  for  the  reverse 
direction  of  that  connection  is  "piggybacked”  onto  it,  using  the  Acknowledgement  field  in  the 
packet  header,  for  interactive  applications,  where  there  is  much  trallic  in  both  dilations,  this 
provides  all  the  necessary  acknowledgement  and  receipting  with  no  nca!  to  send  any  extra  packets 
through  the  network. 


When  this  does  not  siilliie.  SIS  (status)  packets  are  generated  to  c.urv  i  vapts  and 
acknowledgements.  S’IS  packets  aie  mw-miioMed,  since  they  cue  pail  of  the  nn,  h  anisin  that 
implements  controlled  packets.  It  an  S I  v>  picket  is  dupluated.  u  doc-  no  harm.  It  an  SIS 
packet  is  lost  mechanisms  exist  which  will  can-e  a  replacement  m  he  eeneiatcd  later  All  SI'S 
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packet  carries  separate  receipt  and  acknowledgement  packet  numbers. 

When  a  user  process  reads  a  packet  from  the  network,  if  the  number  of  packets  which  should 
have  been  acknowledged  but  have  not  been  is  more  than  i/3  the  window  size,  an  S'i'S  is 
generated  to  acknowledge  them.  Thus  the  preferred  batch  si/c  for  acknowledgement  is  1/3  the 
window  size.  The  advantage  of  this  size  is  that  if  one  STS  is  lost,  another  will  be  generated 
before  the  window  fills  up  (at  the  2/3  point). 

When  a  packet  is  received  with  the  same  packet  number  as  one  which  has  already  been 
successfully  received,  this  is  evidence  of  unnecessary  retransmission,  and  an  SI'S  is  generated  to 
carry  a  receipt  back  to  the  sender.  If  this  S  TS  is  lost,  the  next  retransmission  will  stimulate 
another  one.  Thus  receipts  arc  normally  implied  by  acknowledgements,  and  only  sent  separately 
when  there  is  evidence  of  unnecessary  retransmission. 

Retransmission  consists  of  sending  all  unreceipted  controlled  packets,  except  those  that  were 
last  sent  very  recently  (within  1/30’th  of  a  second  in  ITS.)  Retransmission  occurs  every  1/2 
second.  This  interval  is  somewhat  arbitrary,  but  should  be  close  to  the  response  time  of  the 
systems  involved.  Retransmission  also  occurs  in  response  to  an  STS  packet,  so  that  a  receiver 
may  cause  a  faster  rctranmission  rate  titan  twice  a  second  if  it  so  desires,  litis  should  never  cause 
useless  retransmission,  since  SIS  carries  a  receipt,  and  vcry-rcccntly-transmittcd  packets,  which 
might  still  be  in  transit  through  the  network,  arc  not  retransmitted. 

Another  operation  is  probing,  which  consists  of  sending  a  SNS  packet,  in  the  hope  of 
eliciting  cither  an  STS  or  a  LOS,  depending  on  whether  the  other  side  believes  the  connection 
exists.  Probing  is  used  periodically  as  a  way  of  testing  that  the  connection  is  still  open,  and  also 
serves  as  a  way  to  get  STS  packets  retransmitted  as  a  hedge  against  the  loss  of  an 
acknowledgement,  which  could  otherwise  stymie  the  connection.  SNS  packets  are  uncontrolled. 

We  probe  every  five  seconds  on  connections  which  have  unacknowledged  packets  outstanding 
(a  non-empty  window)  and  on  connections  which  have  not  received  any  packets  (neither  data  nor 
control)  for  one  minute.  If  a  connection  receives  no  packets  for  1  1/2  minutes,  this  means  that  at 
least  5  probes  have  been  ignored,  and  the  connection  is  declared  to  be  broken;  either  the  remote 

host  is  down  or  there  is  no  viable  path  through  die  network  between  the  two  hosts. 

The  receiver  can  generate  "spontaneous”  STS’s,  to  stimulate  retransmission  and  keep  tilings 
moving  on  fast  devices  with  insufficient  buffering  for  1/2  second  worth  of  packets.  This  provides 
a  way  for  the  receiver  to  speed  up  the  retransmission  timeout  in  the  sender,  and  to  make  sure 
that  acknowledges  are  happening  often  enough. 

Note  that  the  network  still  functions  if  cither  or  both  parties  to  a  connection  ignore  the 
window.  1  lie  window  is  simply  an  improver  of  efficiency.  Receipts  have  the  same  property.  This 
allows  very  small  implementations  to  be  compatible  with  the  same  protocol,  which  is  useful  for 
applications  such  as  bootstrapping  through  the  network. 

It  would  lie  possible  to  have  dynamic  adjustment  of  the  window  size  in  response  to  observed 
behavior.  Ihe  SIS  packet  includes  the  window  size  so  that  changes  to  it  can  be  communicated. 
However,  ibis  has  not  been  found  necessary  in  practice.  Inch  higher  level  protocol  has  a  standard 
pic  deleimm  d  window  size,  which  it  establishes  when  it  liist  opens  a  connection,  and  this  seems 

to  be  (lose  enough  to  optimum  tint  c.nelu!  dvnnmn  .nliuslmeul  of  u  wouldn't  make  a  big 

dilleience. 
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This  scheme  for  flow-control  and  error-control  is  based  on  several  assumptions.  It  is  assumed 
that  the  underlying  transmission  media  have  their  own  checking,  so  that  they  discard  all  damaged 
packets,  making  packet  checksums  unnecessary  at  the  protocol  level.  The  transit  time  through  the 
network  is  assumed  to  be  fast,  so  that  a  fairiy-small  retransmission  interval  is  practical,  and 
negative  acknowledgements  are  not  necessary.  The  error  rate  is  assumed  to  be  low  so  that  overall 
efficiency  is  not  affected  by  the  simple-minded  error  recovery  scheme  of  simply  retransmitting  all 
outstanding  packets.  It  is  assumed  that  no  reformatting  of  packets  occurs  inside  the  network,  so 
that  flow-control  and  error-control  can  operate  on  a  packet  basis  rather  than  a  byte  basis. 
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4.  Software  Protocol-Details 

In  the  following  sections,  each  of  the  packet  Opcodes  and  the  use  of  that  packet  type  in  the 
protocol  is  described.  Opcodes  arc  given  as  an  octal  number,  a  three-letter  code,  and  a  name. 

Unless  otherwise  specified,  the  use  of  the  fields  in  the  packet  header  is  as  follows.  The 
source  and  destination  address  and  index  denote  the  two  ends  of  the  connection;  when  an  end 
does  not  exist,  as  during  initial  connection  establishment,  that  index  is  zero.  The  opcode,  byte 
count,  and  forwarding  count  fields  have  no  variations.  The  packet  number  field  contains 
sequential  numbers  in  controlled  packets;  in  uncontrolled  packets  it  contains  the  same  number  as 
the  next  controlled  packet  will  contain.  The  acknowledgement  field  contains  the  packet  number  of 
the  last  packet  seen  by  the  user. 

4.1  Connection  Establishment 

The  following  packet  types  are  associated  with  creating  and  destroying  connections.  First  the 
packets  are  described  and  then  the  details  of  the  various  connection-establishment  protocols  are 
given. 

1  RFC  Request  for  connection 

Ail  connections  are  initiated  by  the  transmission  of  an  RFC  from  the  user  to  the  server.  The 
data  field  of  the  packet  contains  the  contact  name.  1'he  contact  name  can  be  followed  by 
arbitrary  arguments  to  the  server,  delimited  by  a  space  character.  The  destination  index  field  of 
an  RFC  contains  0  since  the  destination  index  is  not  known  yet. 

RFC  is  a  controlled  packet;,  it  is  retransmitted  until  some  sort  of  response  is  received. 
Because  RFC's  arc  not  sent  over  normal,  error-controlled  connections,  a  special  way  of  detecting 
and  discarding  duplicates  is  required.  When  an  NCP  receives  an  RFC  packet,  it  checks  all 
pending  RFC’s  and  all  connections  which  arc  in  the  Open  or  RFC-received  state  (see  section  4.6, 
page  25),  to  see  if  the  source  address  and  index  match;  if  so,  the  RFC  is  a  duplicate  and  is 
discarded. 

12  LSN  Listen 

A  server  process  informs  the  local  NCP  of  the  contact  name  to  which  it  is  listening  by 
sending  a  I.SN  packet,  with  the  contact  name  in  the  data  field.  This  packet  is  never  transmitted 
anywhere  through  the  network.  It  simply  serves  as  a  convenient  buffer  to  hold  the  server's  contact 
name.  When  an  RFC  and  a  I.SN  containing  the  same  contact  name  meet,  the  I.SN  is  discarded 
and  live  RI  C  is  given  to  the  server,  putting  its  connection  into  the  RFC-received  slate  (sec  section 
4.6,  page  25).  I  he  server  reads  the  RFC  and  decides  whether  or  not  to  open  the  connection. 


2  OPN  Open  connection 

OPN  is  the  usual  positive  response  to  RFC.  The  source  index  field  convex s  the  server's  index 
number  to  die  user;  the  user’s  index  number  was  conveyed  m  the  RFC.  I  he  data  field  <>|  OPN 
is  the  same  as  that  of  S  I  S  (sec  below);  it  serve,  in.iinl)  to  u>nvc>  the  server's  window  si/e  to  the 
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user.  The  Acknowledgement  field  of  the  OPN  acknowledges  the  RFC  so  that  it  will  no  longer  be 
retransmitted. 

OPN  is  a  controlled  packet;  it  is  retransmitted  until  it  is  acknowledged.  Duplicate  OPN 
packets  arc  detected  in  a  special  way;  if  an  OPN  is  received  for  a  connection  which  is  not  in  the 

RFC-sent  slate  (sec  section  4.6,  page  25),  it  is  simply  discarded  and  an  SI'S  is  sent.  This  can 

happen  if  the  connection  is  opened  while  a  retransmitted  OPN  packet  is  in  transit  through  the 

network,  or  if  the  SIS  which  acknowledges  an  OPN  is  lost  in  the  network. 

3  CLS  Close  connection 

CI.S  is  the  negative  response  to  RFC.  It  indicates  that  no  server  was  listening  to  the  contact 
name,  and  one  couldn’t  he  created,  or  for  some  reason  the  server  didn’t  feel  like  accepting  this 
request  for  a  connection,  or  the  destination  NCP  was  unable  to  complete  the  connection  (c.g. 
connection  table  full.) 

CI.S  is  also  used  to  close  a  connection  after  it  has  been  open  for  a  while.  Any  data  packets 
in  transit  may  be  lost.  Protocols  which  require  a  reliable  end-of'-data  indication  should  use  the 

mechanism  for  that  (see  section  4.4,  page  24)  before  sending  CFS. 

The  data  field  of  a  CLS  contains  a  character-string  explanation  of  the  reason  for  closing, 
intended  to  be  returned  to  a  user  as  an  error  message. 

CLS  is  an  uncontrolled  packet,  so  that  the  program  which  sends  it  may  go  away  immediately 
afterwards,  leaving  nothing  to  retransmit  the  CLS.  Since  there  is  no  error  recovery  or 
retransmission  mechanism  for  CLS,  the  use  of  CLS  is  necessarily  optional;  a  process  could  simply 
stop  responding  to  its  connection.  However,  it  is  desirable  to  send  a  CLS  when  possible  to 
provide  an  error  message  for  the  user. 

4  FWD  Forward  a  request  for  connection 

This  is  a  response  to  RFC  which  indicates  that  the  desired  service  is  not  available  from  the 
process  contacted,  but  may  be  available  at  a  possibly-diffcrcnt  contact  name  at  a  possibly -different 
host.  The  data  field  contains  the  new  contact  name  and  the  Acknowledgement 
field — exceptionally — contains  the  new  host  number.  The  issuer  of  the  RFC  should  issue  another 

RFC  to  that  address.  FWD  is  an  uncontrolled  packet;  if  it  is  lost  in  the  network,  the 

retransmission  of  the  RFC  will  presumably  stimulate  an  identical  FWD. 

5  ANS  Answer  to  a  simple  transaction 

This  is  another  kind  of  response  to  RFC.  The  data  field  contains  the  entirety  of  the  response, 
and  no  connection  is  established.  ANS  is  an  uncontrolled  packet;  if  it  is  lost  in  the  network,  Lite 
retransmission  of  the  RFC  will  p/vsimiaMy  stimulate  an  identical  ANS. 

there  are  several  eonneeliou  initiation  pmtoeols  implemented  with  these  packet  types. 

When  an  RFC  , nines  at  .i  host,  ih  N(  p  finds  a  usei  proee.s  that  is  liMenine  for  tins  RI  C's 
contact  name,  nr  clears  i  'oner  pro  <•  ■,  in  imnide  the  d-.-.irei  I  sen  ice.  or  ivponds  in  the  RFC 
itself  if  it  knows  how  to  provide  the  lequo  n  d  '-.iviee.  oi  refuses  the  icqucst  lor  connection.  I  lie 
process  that  .cues  the  RFC  chooses  vvhnb  1 1  nnei  lion -initiation  protocol  to  follow.  'I  lie.  process  is 
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given  the  RFC  as  data,  so  that  it  can  look  at  the  contact  name  and  any  arguments  that  may  be 
present 

A  stream  connection  is  initiated  by  an  RFC,  transmitted  from  user  to  server.  The  server 
returns  an  OPN  to  the  user,  which  responds  with  an  STS.  These  three  packets  convey  the  -source 
and  destination  addresses,  indices,  initial  packet  numbers,  and  window  sizes  between  the  two 
NCR’s.  In  addition  a  character-string  argument  can  be  conveyed  from  the  user  to  the  server  in 
the  RFC. 

The  OPN  serves  to  acknowledge  the  RFC  and  extinguish  its  retransmission.  It  also  carries  the 
server’s  index,  initial  packet  number,  and  window  size.  The  SI'S  serves  to  acknowledge  the  OPN 
and  extinguish  its  retransmission.  It  also  carries  the  user’s  window  size;  the  user's  index  and 
initial  packet  number  were  carried  by  the  RFC.  Retransmission  of  the  RFC  and  die  OPN 
provides  reliability  in  the  face  of  lost  packets.  If  the  RFC  is  lost,  it  will  be  retransmitted.  If  the 
S  I'S  is  lost,  the  OPN  will  be  retransmitted.  If  the  OPN  is  lost,  the  RFC  will  be  retransmitted 
superfluously  and  the  OPN  will  be  retransmitted  since  no  STS  will  be  sent. 

The  exchange  of  an  OPN  and  an  STS  tells  each  side  of  the  connection  that  the  other  side 
believes  the  connection  is  open;  once  this  has  happened  data  may  begin  to  flow  through  the 
connection.  The  user  process  may  begin  transmitting  data  when  it  sees  the  OPN.  The  server 
process  may  begin  transmitting  data  when  it  sees  the  STS.  These  rules  ensure  that  data  packets 
cannot  arrive  at  a  receiver  before  it  knows  and  agrees  that  the  connection  is  open.  If  data  packets 
did  arrive  before  then,  the  receiver  would  reject  them  with  a  l.OS  (see  below),  believing  them  to 
be  a  violation  of  protocol,  and  this  would  destroy  the  connection  before  it  was  ever  Hilly 
established. 

Once  data  packets  begin  to  flow,  they  arc  subject  to  the  flow  and  error  control  protocol 
described  in  section  3.8,  page  16.  Thus  a  stream  connection  provides  the  desired  reliable, 
bidirectional  data  stream. 

A  refusal  is  initiated  by  an  RFC  in  the  same  way,  but  the  server  returns  Cl.S  rather  than 
OPN.  The  data  field  of  the  CI.S  contains  die  reason  for  refusal  to  connect. 

A  forwarded  connection  is  initiated  by  an  RFC  in  the  same  way,  but  the  server  returns  a 
I  Wl),  telling  die  user  another  place  to  look  for  the  desired  service. 

A  simple  transaction  is  initiated  by  an  RFC  from  user  to  server,  a  nil  completed  by  an  ANS 
from  server  to  user.  Since  a  full  connection  is  not  established  and  the  reliable-transmission 
mechanism  of  connections  is  not  used,  the  user  process  cannot  he  sure  how  many  copies  of  the 
RI'C  the  server  saw,  and  the  server  process  cannot  be  sure  that  its  answer  got  hack  to  the  user. 
Ibis  means  lli.il  simple  li.m.actious  should  not  he  used  for  applications  where  it  is  important  to 
know  whether  (he  transaction  was  really  completed,  nor  for  applications  in  which  repealing  die 
same  rpieiy  might  produce  a  dillercnl  answer.  Simple  transactions  are  a  simple  efficient 
mw  li, mi  an  for  applications  such  as  extracting  a  small  piece  of  information  (e.u.  the  time  of  day) 
fioin  a  central  data-base. 
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4.2  Status 

7  STS  Status 

STS  is  an  uncontrolled  packet  which  is  used  to  convey  status  information  between  NCPs.  ITie 
Acknowledgement  field  in  the  packet  header  contains  an  acknowledgement,  that  is,  the  packet 
number  of  the  last  packet  given  to  the  receiving  user  process.  The  first  16-bit  byte  in  the  data 
field  contains  a  receipt,  that  is,  a  packet  number  such  that  all  controlled  packets  up  to  and 
including  that  one  have  been  successfully  received  by  the  NCP.  The  second  16-bit  byte  in  the 
data  field  contains  die  window  size  for  packets  sent  in  the  opposite  direction  (to  the  end  of  the 
connection  which  sent  die  SI'S).  The  byte  count  is  presendy  always  4.  This  will  change  if  the 
protocol  is  revised  to  add  additional  items  to  the  S  I'S  packet. 

6  SNS  Sense  status 

SNS  is  an  uncontrolled  packet  whose  sole  purpose  is  to  cause  the  other  end  of  the  connection 
to  send  back  an  S  I'S.  This  is  used  by  die  probing  mechanism  described  above  (see  page  18). 

11  LOS  I.ossage 

LOS  is  an  uncontrolled  packet  which  is  used  by  one  NCP  to  inform  another  of  an  error.  The 
data  field  contains  a  character-string  explanation  of  die  problem.  The  source  and  destination 
addresses  and  indices  arc  simply  the  destination  and  source  addresses  and  indices,  respectively,  of 
die  erroneous  packet,  and  do  not  necessarily  correspond  to  a  connection.  When  an  NCP  receives 
a  LOS  whose  destination  corresponds  to  an  existent  connection  and  whose  source  corresponds  to 
die  supposed  other  end  of  that  connection,  it  breaks  die  connection  and  makes  the  data  field  of 
the  LOS  available  to.  the  user  as  an  error  message.  Other  l.OS’s,  that  don’t  correspond  to 
connections,  arc  simply  ignored. 

l.OS  is  sent  in  response  to  situations  such  as:  arrival  of  a  data  packet  or  an  STS  for  a 
connection  that  docs  not  exist  or  is  not  open,  arrival  of  a  packet  from  die  wrong  source  for  its 
destination,  arrival  of  a  packet  containing  an  undefined  opcode  or  too  large  a  byte  count,  etc. 

I.OS’s  arc  given  to  the  user  process  so  that  it  may  read  the  error  message. 

No  l.OS  is  given  in  response  to  an  OPN  to  a  connection  not  in  the  Kl'C-Scnt  state,  nor  in 
response  to  a  SNS  to  a  connection  not  in  the  Open  state,  nor  in  response  to  a  I  OS  to  a  non¬ 
existent  or  broken  connection.  These  rules  are  important  to  niaCe  the  protocols  work  without 
timing  errors.  An  OPN  or  a  SNS  to  a  non-existent  connection  elicits  a  LOS. 


I  >SK:MOON. A:\llll  l<  1(1/ 


IS-JKN  81 


Data 


24 


Chaosnet 


4.3  Data 

200-277  OAT  8-bit  Daw 

Opcodes  200  through  277  (octal)  arc  controlled  packets  with  user  data  in  8-bit  bytes  in  the 
data  field.  The  NCP  treats  all  64  of  these  opcodes  identically;  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes.  The  standard  default  opcode  is  200. 

300-377  DAT  16-bit  Data 

Opcodes  300  through  377  (octal)  are  controlled  packets  with  user  data  in  16-bit  bytes  in  the 
data  field.  The  NCP  treats  all  64  of  these  opcodes  identically;  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes.  T  he  standard  default  opcode  for  16-bit  data  is  300. 

16  UNO  Uncontrolled  Data 

This  is  an  uncontrolled  packet  with  user  data  in  8-bit  bytes  in  the  data  field.  It  exists  so  that 

user-level  programs  may  bypass  the  flow-control  mechanism  of  Chaosnet  protocol.  Note  that  the 
NCI’  is  free  to  discard  these  packets  at  any  time,  since  they  arc  uncontrolled.  Since  UNC’s  are 
not  subject  to  flow  control,  discarding  may  be  necessary  to  avoid  running  out  of  buffers.  A 
connection  may  not  have  more  input  packets  queued  awaiting  the  attention  of  the  user  program 
than  the  window  size  of  the  connection,  except  that  you  arc  always  allowed  to  have  one  UNC 
packet  queued.  If  no  normal  data  packets  arc  in  use,  up  to  one  more  UNC  packet  than  the 
window  size  may  be  queued. 

UNC  packets  arc  also  used  by  the  standard  protocol  for  encapsulating  packets  of  foreign 
protocols  for  transmission  through  Chaosnet  (see  chapter  6,  page  32). 

4.4  End-of-Data 

14  EOF  KndofPife 

HOI-  is  a  controlled  packet  which  serves  as  a  "logical  end  of  data"  mark  in  the  packet  stream. 
When  the  user  program  is  ignoring  packets  and  treating  a  Chaosnet  connection  as  a  conventional 
byte-stream  I/O  device,  the  NCP  uses  the  HOH  packet  to  convey  the  notion  of  conventional  end- 
ol'-lilc  from  one  end  of  the  connection  to  the  other.  When  the  user  program  is  working  at  the 
packet  level,  it  may  transmit  and  receive  KOF’s. 

HOI-  packets  are  used  in  the  following  protocol  which  is  the  recommended  way  to  reliably 
determine  that  all  data  have  been  transferred  before  dosing  a  connection  (in  applications  where 
that  is  an  impoitant  consideration). 

The  important  issue  is  that  neither  side  may  send  a  CI  S  until  both  sides  are  sure  that  all  the 
cl  it  i  hoe  been  transmitted.  After  sending  all  the  data  it  is  going  to  send,  including  an  HOI 
pukci  to  m. uk  the  end.  the  sending  p rex  ess  waits  for  all  packets  to  lx-  acknowledged.  T  his 
■  a,  in,-,  dial  the  ivniw  r  has  seen  all  the  data  and  knows  lliai  no  more  data  .no  to  come.  Ihe 
i -d  in-  lie  n  ilu.'-s  ihe  i.oiiiu  1. 1  mu.  When  lli.  o  i  ei\ mg  pioce.s  sees  an  I  til-  u  knows 
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until  a  brief  timeout  elapses.  The  timeout  is  to  provide  for  the  ease  where  the  sender’s  CHS  gets 
lost  in  the  network  (CI.S  cannot  be  retransmitted).  The  timeout  is  long  enough  (a  few  seconds) 
to  make  it  unlikely  that  the  sender  will  not  have  seen  die  acknowledgement  of  the  HOI-  by  the 
time  die  umcout  is  over. 

To  use  this  protocol  in  a  bidirectional  fashion,  where  both  parties  to  die  connection  are 
sending  data  simultaneously,  it  is  necessary  to  use  an  asymmetrical  protocol.  Arbitrarily  call  one 
party  the  user  and  the  other  die  server.  The  pm'-tcol  is  that  after  sending  all  its  data,  each  party 
sends  an  HOF  and  waits  for  it  to  be  acknowledged.  The  server,  having  seen  its  HOF 
acknowledged,  sends  a  second  EOF.  The  user,  having  seen  its  HOF  acknowledged,  looks  for  a 
second  HOF  and  then  sends  a  CHS  and  goes  away.  The  server  goes  away  when  it  sees  the  user’s 
CHS,  or  after  a  brief  timeout  has  elapsed.  This  asymmetrical  protocol  guarantees  diat  each  side 
gets  a  chance  to  know  that  both  sides  agree  that  all  the  data  have  been  transferred.  The  first 
CL.S  will  only  be  sent  after  both  sides  have  waited  for  their  (first)  HOF  to  be  acknowledged. 

4.5  Low-level 

13  MNT  Maintenance 

MNT  is  a  special  packet  type  reserved  for  the  use  of  network  maintenance  programs.  Normal 
NCPs  should  simply  discard  any  MNT  packets  they  receive.  MNT  packets  arc  an  escape 
mechanism  to  allow  special  programs  to  send  packets  that  arc  guaranteed  not  to  get  confused  with 
normal  packets.  MNT  packets  arc  forwarded  by  bridges  although  usually  one  would  not  be 
depending  on  this. 

10  RUT  Routing  Information 

RUT  is  a  special  packet  type  broadcast  by  bridges  to  inform  other  nodes  of  the  bridge’s 
ability  to  forward  packets  between  subnets.  1'hc  source  address  is  the  network  address  of  the 
bridge  on  the  subnet  on  which  the  RUT  was  broadcast,  flic  destination  address  is  zero.  The 
byte  count  is  a  multiple  of  4,  and  the  data  field  contains  a  series  of  pairs  of  16-bit  bytes:  a 
subnet  number  and  the  "cost"  of  getting  to  that  subnet  via  this  bridge.  T  he  packet  number  and 
acknowledgement  fields  are  not  used  and  should  contain  zero.  See  section  3.7,  page  13  for  the 
details. 

4.6  Connection  States 

A  user  process  gets  to  Chaosnet  by  means  of  a  capability  or  channel  (dependent  on  the  host 
operating  system)  which  corresponds  to  one  end  of  a  connection.  Associated  with  this  channel  arc 
a  number  of  bullets  containing  controlled  packets  output  by  the  user  and  not  yet  receipted,  and 
data  packets  received  from  the  network  but  not  yet  read  by  the  user:  some  of  these  incoming 
packets  arc  in-order  Ivy  packet  number  and  hence  may  be  read  by  the  user,  while  others  are  out 
of  order  and  cannot  be  read  until  packets  cailier  in  the  stream  have  been  icccivcd.  Ceitnin 
control  packets  me  also  given  to  the  user  as  if  they  were  data  packets.  These  ate  KK'.  ANS, 
f T  S,  HOS.  HOF,  and  UNO.  HOF  is  ifie  only  type  that  can  ever  be  oul-ol  older. 
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Also  associated  with  the  channel  is  a  state,  usually  called  the  connection  state.  Full 
understanding  of  these  states  depends  on  the  descriptions  of  packet-types  above.  The  state  can  be 
one  of: 


Open  The  connection  exists  and  data  may  be  transferred. 

Closed  'rhe  channel  does  not  have  an  associated  connection.  Either  it  never  had  one  or  it 

has  received  or  transmitted  a  CLS  packet,  which  destroyed  the  connection. 


Listening 
RFC  Received 
RFC  Sent 
Lost 


The  channel  docs  not  have  an  associated  connection,  but  it  has  a  contact  name 
(usually  contained  in  a  LSN  packet)  for  which  it  is  listening. 

A  Listening  channel  enters  this  state  when  an  RFC  arrives.  It  can  become  Open 
if  the  user  process  accepts  the  request. 

The  user  has  transmitted  an  RFC.  The  state  will  change  to  Open  or  Closed  when 
the  reply  to  the  RFC  comes  back. 

The  connection  has  been  broken  by  receiving  a  LOS  packet. 


Incomplete  Transmission 

The  connection  has  been  broken  because  the  other  end  has  ceased  to  transmit  and 
to  respond  to  SNS.  Hither  the  network  or  the  foreign  host  is  down.  (This  can 
also  happen  if  the  local  host  goes  down  for  a  while  and  then  is  revived,  if  its 
dock  runs  in  the  meantime.) 


Foreign  The  channel  is  talking  some  foreign  protocol,  whose  packets  arc  encapsulated  in 

UNC  packets.  As  far  as  Chaosnet  is  concerned  there  is  no  connection.  See 
chapter  6,  page  32  for  the  details. 
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5.  Higher-Level  Protocols 

This  chapter  briefly  documents  some  of  the  higher-level  protocols  of  the  most  general  interest. 
There  arc  quite  a  few  other  protocols  which  are  too  specialized  to  mention  here.  All  protocols 
other  titan  the  STATUS  protocol  are  optional  and  are  only  implemented  by  those  hosts  that  need 
them.  All  hosts  arc  required  to  implement  the  STATUS  protocol  since  it  is  used  for  network 
maintenance. 

5.1  Status 

All  network  nodes,  even  bridges,  arc  required  to  answer  RFC’s  with  contact  name  STATUS, 
returning  an  ANS  packet  in  a  simple  transaction.  This  protocol  is  primarily  used  for  network 
maintenance.  The  answer  to  a  STATUS  request  should  be  generated  by  the  Network  Control 
Program,  rather  than  by  starting  up  a  server  process,  in  order  to  provide  rapid  response. 

'Hie  STATUS  protocol  is  used  to  determine  whether  a  host  is  up.  to  determine  whether  an 
operable  path  through  the  network  exists  between  two  hosts,  to  monitor  network  error  statistics, 
and  to  debug  new  Network  Control  Programs  and  new  Chaosnet  hardware.  The  hostat  function 
on  the  Lisp  machine,  and  the  Hostat  command  of  the  CHATST  program  on  ITS  arc  user  ends 
for  this  protocol. 

T  he  first  32  bytes  of  the  ANS  contain  the  name  of  the  node,  padded  on  the  right  with  zero 
bytes.  T  he  rest  of  the  packet  contains  blocks  of  information  expressed  in  16-bit  and  32-bit  words, 
low  byte  first  (pdpl  1/Lisp  machine  style).  The  low-order  half  of  a  32-bit  word  comes  first.  Since 
ANS  packets  contain  8-bit  data  (not  16-bit),  machines  such  as  pdplOs  which  store  numbers  high 
byte  first  will  have  to  shuflle  the  bytes  when  using  this  protocol.  T  he  first  16-bit  word  in  a  block 

is  its  identification.  The  second  16-bit  word  is  the  number  of  16-bit  words  to  follow.  The 

remaining  words  in  the  block  depend  on  the  identification. 

This  is  the  only  block  type  currently  defined.  All  items  arc  optional,  according  to  the  count 

field,  and  extra  items  not  defined  here  may  be  present  and  should  be  ignored.  Note  that  items 

after  the  first  two  arc  32-bit  words. 

wordO  A  number  between  400  and  777  octal.  This  is  400  plus  a  subnet  number.  This 

block  contains  information  on  this  host’s  direct  connection  to  that  subnet. 

word  1  The  number  of  16-bit  words  to  follow,  usually  16. 

words  2-3  The  number  of  packets  received  from  this  subnet. 

words 4-5  The  number  of  packets  transmitted  to  this  subnet. 

words  6-7  I  he  number  of  transmissions  to  this  subnet  aborted  by  collisions  or  because  the 

receiver  was  busy. 

words  8-9  T  he  number  of  incoming  packets  from  this  subnet  lost  because  the  host  had  not 
yet  read  a  previous  packet  out  of  die  interface  and  consequently  the  interface 
could  not  capture  the  packet. 

words  10-11  I  he  number  of  incoming  packets  from  this  subnet  with  CRC  errors.  I  lic  e  v\cre 
either  irnnsniiiled  wiom;  or  damaged  in  transmission. 
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words  12-13  The  number  of  incoming  packets  from  this  subnet  which  had  no  CRC  error  when 
received,  but  did  have  an  error  after  being  read  out  of  the  packet  buffer.  'Hi is 
error  indicates  cither  a  hardware  problem  with  the  packet  buffer  or  an  incorrect 
packet  length. 

words  14-15  The  number  of  incoming  packets  from  this  subnet  which  were  rejected  due  to 
incorrect  length  (typically  not  a  multiple  of  16  bits). 

words  16-17  The  number  of  incoming  packets  from  this  subnet  rejected  for  other  reasons  (c.g. 

too  short  to  contain  a  header,  garbage  byte-count,  forwarded  too  many  times.) 

If  the  identification  is  a  number  between  0  and  377  octal,  this  is  an  obsolete  format  of  block. 
The  identification  is  a  subnet  number  and  the  counts  arc  as  above  except  that  they  are  only  16 
bits  instead  of  32,  and  consequently  may  overflow.  This  format  should  no  longer  be  sent  by  any 
hosts. 

Identification  numbers  of  1000  octal  and  up  are  reserved  for  future  use. 

5.2  Pulsar 

For  network  maintenance  purposes,  certain  network  nodes  support  a  simple  transaction  with 
contact  name  PULSAR,  which  controls  a  "pulsar"  feature.  This  feature  periodically  transmits  a 
short  packet  which  can  be  used  to  test  and  adjust  cable  transceivers.  The  packet  consists  of  the 
three  header  words,  a  zero  word,  and  a  word  of  alternating  ones  and  zeros.  It  is  addressed  to 
host  177777  which  is  guaranteed  not  to  exist. 

The  returned  ANS  contains  a  single  character,  which  is  a  digit.  A  0  means  that  the  pulsar  is 
turned  off.  Any  other  digit  indicates  the  number  of  sixtieths  of  a  second  between  pulses.  Sending 
an  RFC  with  a  digit  as  an  argument  sets  die  state  of  the  pulsar  to  diat  digit,  and  returns  an  ANS 
containing  the  new  state. 

5.3  Telnet  and  Supdup 

The  Telnet  and  Supdup  protocols  of  die  Arpanet  fl  Hl.NFT]  [SUPDUP]  exist  in  identical  form 
in  Chaosnet.  These  protocols  allow  access  to  a  computer  system  as  an  interactive  terminal  from 
another  network  node. 

The  contact  names  arc  TELNET  and  SUPDUP.  The  direct  borrowing  of  the  Iclnct  and 
Supdup  protocols  was  eased  by  their  use  of  S-hit  byte  streams  and  only  a  single  connection.  Note 
that  these  protocols  define  their  own  character  sets,  which  differ  from  each  other  and  from  the 
t  haosnet  standard  character  set 

Chaosnet  contains  no  counterpart  of  die  INR/INS  attention-getting  feature  of  the  Arpanet. 

I  he  Telnet  protocol  sends  a  packet  with  opcode  .70!  in  place  of  the  INS  signal,  fhis  is  a 
controlled  packet  ami  hence  docs  not  provide  the  "out  of  ham!"  feature  of  the  Arpanet  INS, 
however  it  is  satisfactory  lor  the  I 'el  net  "interrupt  process"  and  "discard  output"  operations  on  the 
kinds  of  hosts  attached  to  Chaosnet. 
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5.4  File  Access 

The  HI.K  protocol  is  primarily  used  by  l  isp  machines  to  access  files  on  network  file  servers. 
I  I  S  and  TOPS-20  arc  equipped  to  act  as  file  servers.  A  user  end  for  die  file  protocol  also  exists 
for  TOPS-20  and  is  used  for  general-purpose  file  transfer.  For  complete  documentation  on  the  file 
protocol,  see  |FII.K|.  I'hc  Arpanet  file  transfer  protocols  have  not  been  implemented  on  the 
Chaosnet  (except  through  the  Arpanet  gateway  described  below). 


5.5  Mail 

The  MAIL  protocol  is  used  to  transmit  inter-user  messages  through  the  Chaosnet.  I'hc 
Arpanet  mail  protocol  was  not  used  because  of  its  complexity  and  poor  state  of  documentation. 
Iliis  simple  protocol  is  by  no  means  die  last  word  in  mail  protocols;  however,  it  is  adequate  for 
the  mail  systems  we  presently  possess. 

The  sender  of  mail  connects  to  contact  name  MAIL  and  establishes  a  stream  connection.  It 
then  sends  the  names  of  all  the  recipients  to  which  die  inaii  is  to  be  sent  at  (or  via)  die  server 
host.  The  names  are  sent  one  to  a  line  and  terminated  by  a  blank  line  (two  carriage  returns  in  a 
row).  I'hc  Lisp  Machine  character  set  is  used.  A  reply  (see  below)  is  immediately  returned  for 
each  recipient.  A  recipient  is  typically  just  the  name  of  a  user,  but  it  can  be  a  uscr-atsign-host 
sequence  or  anything  else  acceptable  to  the  mail  system  on  the  server  machine.  After  sending  the 
recipients,  the  sender  sends  the  text  of  the  message,  terminated  by  an  HOI'.  After  die  mail  has 
been  successfully  swallowed,  a  reply  is  sent.  After  die  sender  of  mail  has  read  the  reply,  both 
sides  close  the  connection. 

In  the  MAIL  protocol,  a  reply  is  a  signal  from  the  server  to  the  user  (or  sender)  indicating 
success  or  failure.  The  first  character  of  a  reply  is  a  plus  sign  for  success,  a  minus  sign  for 
permanent  failure  (c.g.  no  such  user  exists),  or  a  percent  sign  for  temporary  failure  (c,g.  unable  to 
receive  message  because  disk  is  full),  flic  rest  of  a  reply  is  a  human-readable  character  string 
explaining  the  situation,  followed  by  a  carriage  return. 

The  message  text  transmitted  through  die  mail  protocol  normally  contains  a  header  formatted 
in  the  Arpanet  standard  fashion.  [RFC733J 


5.6  Send 

The  SH'NI)  protocol  is  used  to  transmit  an  interactive  message  (requiring  immediate  attention) 
between  users,  the  sender  connects  to  contact  .mine  SHNI)  at  die  machine  to  which  the  recipient 
is  logged  in.  The  remainder  of  the  RFC  packet  contains  the  name  of  the  person  being  sent  to. 
A  stream  connection  is  opened  and  the  message  is  transmitted,  followed  by  an  HOF.  both  sides 
close  after  following  the  end  of-data  protocol  described  in  section  4.4,  page  24.  I  he  tact  that  the 
RFC  was  responded  to  affirmatively  indicates  that  the  recipient  is  in  fact  present  and  accepting 
messages.  I  lie  message  text  should  begin  with  a  suitable  header,  naming  the  user  lli.it  sent  die 
message.  The  standard  for  such  licadcis,  not  cuncnlly  adhered  to  by  all  hosts,  is  one  line 
formatted  as  in  tin-  following  example: 

Muoni'fll  I  MC  li/lf./SI  ()?:?():  17 

Automatic  nph  to  lit.-  wilder  inn  he  impt.  meuted  In  scare  hint1  lot  the  first  "<« "  and  using  the 
SIND  pmioiol  to  ill  ■  host  follow  in]'  the  "to"  with  the  uigomenl  preceding  it. 
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57  Name 

'ITic  Namc/Fingcr  protocol  of  the  Arpanet  [FINGF.R]  exists  in  identical  form  on  the  Chaosnet. 
Both  l.isp  machines  and  timesharing  machines  support  this  protocol  and  provide  a  display  of  the 
uscr(s)  currently  logged  in  to  them. 

The  contact  name  is  NAME  which  can  be  followed  by  a  space  and  a  string  of  arguments  like 
the  "command  line"  of  the  Arpanet  protocol.  A  stream  connection  is  established  and  the  "finger" 
display  is  output  in  I.isp  Machine  character  set,  followed  by  an  EOF. 

l.isp  Machines  also  support  the  F1NGHR  protocol,  a  simple-transaction  version  of  the  NAME 
protocol.  An  RFC  with  contact  name  FINGER  is  transmitted  and  the  response  is  an  ANS 
containing  the  following  items  of  information  separated  by  carriage  returns:  the  logged-in  user  ID, 
the  location  of  the  terminal,  the  idle  time  in  minutes  or  hours-colon-minutes,  the  user's  full 
name,  and  the  user’s  group  affiliation. 


5.8  Time 

The  Time  protocol  of  the  Arpanet  f TIME]  exists  on  Chaosnet  as  a  simple  transaction.  An 
RFC  to  contact  name  TIME  evokes  an  ANS  containing  the  number  of  seconds  since  midnight 
Greenwich  Mean  Time,  Jan  1,  1900  as  a  32-bit  number  in  four  8-bit  bytes,  least-significant  byte 
first.  Some  computers— l.isp  machines,  for  example— which  don’t  have  hardware  calendar-clocks 
use  this  protocol  to  find  out  the  date  and  time  when  they  first  come  up. 

5.9  Arpanet  Gateway 

This  protocol  allows  a  Chaosnet  host  to  access  almost  any  service  on  the  Arpanet  The 
gateway  server  runs  on  each  IT'S  host  that  is  connected  to  both  networks.  It  creates  an  Arpanet 
connection  and  a  Chaosnet  connection  and  forwards  data  bytes  from  one  U)  the  other.  It  also 
provides  for  a  one-way  auxiliary  connection,  used  for  the  data  connection  of  the  Arpanet  File 
Transfer  Protocol. 

The  RFC  packet  contains  a  contact  name  of  ARPA,  a  space,  the  name  of  the  Arpanet  host  to 
be  connected  to,  optionally  followed  by  a  space  and  the  contact-socket  number  in  octal,  which 
defaults  to  1  if  omitted.  The  Arpanet  Initial  Connection  Protocol  is  used  to  establish  a  bi¬ 
directional  8-bit  connection. 

If  a  data  pricket  with  opcode  201  (octal)  is  received,  an  Arpanet  INS  signal  will  be 
transmitted.  Any  data  bytes  in  this  packet  arc  transmitted  normally. 

If  a  data  packet  with  opcode  210  (octal)  is  received,  an  auxiliary  connection  on  each  network 
is  opened.  The  first  eight  data  bytes  are  the  Chaosnet  contact  name  for  the  auxiliary  connection: 
the  user  should  send  an  RFC  with  this  name  to  the  server.  The  next  lour  data  bytes  are  the 
At  panel  socket  number  to  be  connected  to,  in  the  wrong  order,  most-significant  b\ tc  first.  The 
byte  si/e  of  the  atixiliaiy  connection  is  X  bits. 

I  he  normal  cloving  of  an  Aip  mct  ootinei  lion  cot  re-  ponds  to  an  I  OF  packet,  (  losing  dm:  to 
an  ciiof.  such  as  Host  Dead,  lotiespoiids  to  a  Cl  X  packet. 
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5.10  Dover 

A  press  file  may  be  sent  to  the  Dover  printer  by  connecting  to  contact  name  DOVER  at  host 
AI-CHAOS-11.  1'his  host  provides  a  protocol  translation  service  which  translates  from  Chaosnet 
stream  protocol  to  die  EFTP  protocol  spoken  by  the  Dover  printer.  Only  one  file  at  a  time  can 
be  sent  to  the  Dover,  so  an  attempt  to  use  this  service  may  be  refused  by  a  CI  S  packet 

containing  the  string  "BUSY".  Once  the  connection  has  been  established,  the  press  file  is 

transmitted  as  a  sequence  of  8-bit  bytes  in  data  packets  (opcode  300).  It  is  necessary  to  provide 
packets  rapidly  enough  to  keep  die  Dover’s  program  (Spruce)  from  timing  out;  a  packet  every 
five  seconds  suffices.  Of  course,  packets  are  normally  transmitted  much  more  rapidly. 

Once  the  file  has  been  transmitted,  an  F.OF  packet  must  be  sent.  The  tran  milter  must  wait 
for  that  F.OF  to  be  acknowledged,  send  a  second  one,  then  dose  die  connection.  The  two  F.OF’s 
are  necessary  to  provide  the  proper  connection-closing  sequence  for  the  EFTP  protocol.  Once  the 
press  file  has  been  transmitted  to  the  Dover  in  this  way  and  stored  on  the  Dover’s  local  disk,  it 
will  be  processed  and  prepared  for  printing,  and  then  printed. 

If  an  error  message  is  returned  by  the  Dover  while  the  press  file  is  being  transmitted,  it  will 
be  reported  back  through  the  Chaosnet  as  a  I.OS  containing  the  text  of  the  error  message.  Such 

errors  arc  fairly  common;  the  sender  of  the  press  file  should  be  prepared  to  retry  die  operation  a 

few  times. 

Most  programs  that  send  press  files  to  die  Dover  first  wait  for  the  Dover  to  be  idle,  using  the 
Foreign  Protocol  mechanism  of  Chaosnet  to  check  the  status  of  die  Dover.  This  is  optional,  but 
is  courteous  to  other  users  since  it  prevents  printing  from  being  held  up  while  additional  files  arc 
sent  to  the  Dover  and  queued  on  its  local  disk. 

It  would  be  possible  to  send  to  a  press  file  to  the  Dover  using  its  EFTP  protocol  through  the 
Foreign  Protocol  mechanism,  rather  than  using  the  Ai-CHAOS-11  gateway  service.  This  is  not 
usually  done  because  EFTP,  which  requires  a  handshake  for  every  packet,  lends  to  be  very  slow 
on  a  timesharing  system. 
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6.  Using  Foreign  Protocols  in  Chaosnet 

As  seen  above,  foreign  protocols  which  arc  based  on  the  idea  of  a  bidirectional  (or 
unidirectional)  stream  of  8-bit  bytes  can  simply  be  adopted  wholesale  into  Chaosnet,  using  a 
Chaosnet  stream  connection  instead  of  whatever  stream  protocol  the  protocol  was  originally 
designed  for.  This  was  done  with  the  Arpanet  Telnet  protocol,  for  example. 

When  rising  such  protocols  between  a  Chaosnet  process  and  a  process  on  a  foreign  network,  a 
protocol-translating  gateway  stands  at  the  boundary  between  the  two  networks  and  has  a 
connection  on  both  networks.  Bytes  received  from  one  connection  arc  transmitted  out  the  other. 
If  the  protocol  uses  any  features  besides  a  simple  stream  of  bytes,  for  instance  special  out-of-band 
signals,  these  are  translated  appropriately  by  the  gateway.  Ihe  connection  is  initially  set  up  by 
the  user  end  connecting  explicitly  to  the  protocol-translating  gateway  and  demanding  of  it  a 
certain  service  from  a  certain  host  on  the  other  network;  the  gateway  then  opens  the  appropriate 
pair  of  connections.  For  an  example  of  this,  refer  to  the  Arpanet  gateway  (sec  section  5.9,  page 
30). 


However,  there  are  many  packet-oriented  protocols  in  the  world  and  sometimes  it  is  desirable 
to  access  these  protocols  at  the  packet  level  rather  than  the  connection  level,  and  to  transport  the 
packets  of  these  protocols  through  Chaosnet  links  without  using  a  Chaosnet  connection.  For 
example,  there  are  gateways  attached  to  Chaosnet  which  provide  connections  to  other  networks 
that  use  PUP  and  Internet  as  their  packet  protocols.  User  processes  in  Chaosnet  hosts  may  talk  to 
those  other  networks  in  those  networks'  own  protocols  by  using  the  foreign-protocol  protocol  of 
Chaosnet. 

A  foreign  packet  is  transmitted  through  Chaosnet  by  storing  it  in  the  data  field  of  an  UNC 
packet.  The  foreign  packet  is  regarded  as  being  composed  of  8-bit  bytes.  The  source  and 
destination  addresses  of  the  UNC. packet  are  used  in  the  usual  fashion  to  control  the  delivery  of 
the  packet  within  Chaosnet.  The  packet  number  and  acknowledgement  fields  of  the  packet  header 
arc  not  used  for  their  normal  purposes,  since  this  packet  is  not  associated  with  a  Chaosnet  stream 
connection.  By  convention,  die  acknowledgement  field  of  the  packet  contains  a  protocol  number. 
The  number  100000  octal  means  Internet  and  the  number  100001  octal  means  PUP.  Other 
numbers  will  be  assigned  as  needed.  The  packet  number  field  of  the  packet  can  be  used  for  any 
purpose. 

If  a  user  process  transmits  an  UNC  packet  through  a  Chaosnet  channel  which  is  in  the  Closed 
state  (see  section  4.6.  page  25).  the  channel  goes  into  the  Foreign  state  and  the  NCP  assumes  that 
the  user  is  not  talking  normal  Chaosnet  protocol,  but  is  using  Chaosnet  to  transport  packets  of 
some  other  protocol.  The  NCP  fills  in  the  source  address  and  index  in  these  packets,  but  believes 
whatever  destination  address  and  index  aic  placed  in  the  packet  by  the  user.  The  packet  number 
and  acknowledgement  fields  of  the  UNC  packets  arc  not  touched  by  the  NCP.  Any  incoming 
UNC  packets  addressed  to  the  user's  index  on  this  host  will  be  given  to  the  user,  regardless  of 
their  source  addrcss/iiulex;  it  is  up  to  the  user  program  to  filter  out  any  unwanted  packets.  The 
NCP  should  also  provide  a  way  for  one  user  to  receive  any  unclaimed  incoming  UNC  packets,  so 
that  rendezvous  suhprotocols  of  foreign  protocols  may  be  simulated. 

When  a  packet-translating  gateway  to  a  foreign  network  receives  an  UNC  packet  with  the 
uppiopn.iie  protocol  number,  it  extracts  the  foreign  packet  horn  the  data  field  and  fires  it  into  the 
Ibieign  netwotk.  When  it  receives  packets  fiotii  the  loicign  mlwork.  it  maps  the  destination 
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address  of  die  packet  into  a  Chaosnet  address  and  index  in  some  suitable  fashion,  encapsulates 
die  packet  in  an  UNC,  and  launches  it  into  Chaosnet. 

For  PUP  the  address  mapping  is  straightforward,  since  PUP  and  Chaosnet  use  similar 
addressing  techniques  [KTUKRNET).  The  host  address  spaces  are  the  same.  The  Chaosnet  index 
maps  directly  into  the  low-order  16  bits  of  the  PUP  port  number,  and  the  high-order  16  bits  are 
zero.  When  a  PUP  is  encapsulated  in  a  Chaosnet  packet,  its  PUP  header  duplicates  the  addresses 
in  the  Chaosnet  header.  When  a  PUP  is  received  by  a  PUP/Cbaosnct  g.newa),  a  Chaosnet 
header  can  easily  be  constructed  from  die  PUP  header.  The  Al-CI  I AOS-1 1  is  attached  to  the 
Mil  Chaosnet  and  the  MU'  Ethernet  and  provides  a  PUP/Cliaosnet  gateway.  It  advertises  to 
each  network  its  ability  to  route  packets  to  host  addresses  in  die  other  network,  using  that 
network’s  routing  protocols.  When  it  receives  a  packet  from  one  network  diat  is  destined  for  the 
other,  it  docs  the  appropriate  encapsulation  or  de-encapsulation  and  sends  the  packet  on  its  way. 
AI-CHAOS-11  also  acts  as  a  bridge  between  several  Chaosnet  subnets  and  provides  a  protocol- 
translating  gateway  for  sending  Press  files  to  the  Dover  printer  (a  protocol-translating  gateway  is 
necessary  for  this  application  because  the  printer’s  native  protocol,  which  could  be  used  through 
die  foreign-protocol  protocol,  cannot  be  implemented  efficiently  under  a  timesharing  system). 

In  the  case  of  Internet,  only  protocols  built  on  die  idea  of  ports  can  be  straightforwardly 
supported  without  a  table  of  connections  in  the  gateway.  The  Internet  address  space  includes  the 
Chaosnet  host  address  space  as  a  subset  but  docs  not  provide  any  address  breakdown  within  a 
host  unless  ports  arc  used.  However,  it  appears  that  must  protocols  arc  built  on  a  protocol  that 
uses  ports,  such  as  the  User  Datagram  Protocol  [UDP|  or  the  Transmission  Control  Protocol 
[TCP]. 

In  the  case  of  foreign  protocols  other  than  PUP,  where  the  addressing  structure  is  not 
identical  to  Chaosnet,  a  program  must  somehow  know  the  Chaosnet  address  of  a  packet- 
translating  gateway  to  the  foreign  network.  By  sending  UNC  packets  to  this  gateway,  a  user 
program  can  initiate  connections  to  processes  on  that  other  network  without  requiring  iris  local 
NCP  (nor  any  bridges  involved  in  routing  die  packets)  to  know  anything  about  the  protocol  he  is 
using.  If  die  inter-nctwork  gateway  translates  rendezvous  protocols  appropriately,  connections  may 
be  initiated  in  the  reverse  direction  also — from  a  user  process  on  the  foreign  network  to  a  server 
for  the  foreign  protocol  that  resides  on  a  Chaosnet  iiost. 

'The  foreign-protocol  protocol  may  also  be  used  between  two  user  processes  on  Chaosnet,  with 
no  foreign  network  involved,  if  they  simply  wish  to  speak  a  dillercnt  protocol  from  Chaosnet. 
They  arc  on  their  own  for  a  rendezvous  mechanism,  however,  unless  dies  use  a  Chaosnet  simple 
transaction  for  rendezvous  or  otherwise  have  some  way  of  convoying  their  addresses  and  index 
numbers  to  each  other. 

When  foreign  packets  arc  too  large  to  fit  in  llic  data  field  of  a  Chaosnet  packet  (more  dian 
488  bytes),  the  user  program  and  the  packet-translating  gateway  must  agree  on  a  technique  for 
dividing  packets  into  fragments  and  reassembling  them,  unless  the  foreign  protocol  itself  pro' ides 
for  this,  as  Internet  does.  The  packet -number  field  in  an  UNC  packet  is  available  lor  use  by 
such  a  (cctiiiii|m\  since  UNC  packets  are  not  normally  numhcicd.  This  is  not  a  problem  with 
I ’l II’.  since  il  provides  a  piolocol  hy  which  parties  to  a  connection  and  gateways  may  complain 
about  ovcily-lai.ee  packets  and  specify  the  maximum  packet  si/C  lo  lie  Used. 

I  INC  packets  nut  associated  with  a  connection  ale  useful  foi  oilier  things  besides  encapsulating 
f<  iic'ir  n  protocols.  \ny  application  which  vv.mis  lo  use  (  li  kmh  t  is  simply  a  picket  liniismissioii 
medium,  e-.seiili.illv  the  raw  h  adware.  -Ii-ald  use  l  N(  pallets  mi  dial  its  |».o  kcO-  do  not 
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interfere  with  standard  packets  and  so  that  the  standard  routing  mechanisms  may  be  used.  For 
example,  the  MIT  Architecture  Machine  uses  UNC  packets  to  communicate  with  non-stream- 
oriented  I/O  devices  such  as  graphic  tablets.  Here  Chaosnet  is  being  used  as  an  I/O  bus  which 
may  be  attached  to  more  than  one  computer.  Numbers  between  140000  and  177777  octal  in  the 
acknowledgement  field  of  an  UNC  packet  are  reserved  for  such  applications.  Note  that  this 
number  is  not  part  of  the  protocol;  it  is  simply  a  hint  about  what  a  packet  is  being  used  for. 
Normally  no  program  that  is  not  specifically  supposed  to  deal  with  such  packets  would  ever 
receive  one. 
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7.  Hardware  Programming  Documentation 

This  section  describes  the  Unibus  version  of  the  Chaosnet  interface,  which  attaches  to  pdplls 
and  l  isp  Machines.  The  interface  contains  one  buffer  which  holds  a  received  packet  and  a  second 
buffer  which  holds  a  packet  to  be  transmitted.  Packets  are  moved  between  these  buffers  and  the 
computer  under  program  control.  Direct  memory  access  (DMA)  is  not  used;  the  small  gain  in 
performance  was  not  thought  to  be  worth  the  extra  hardware  complexity.  The  usual  performance 
penalty  of  programmed  I/O  is  not  incurred  since  the  packet  bull'crs  can  transfer  data  at  the  full 
speed  of  the  computer  and  neither  busy  waiting  nor  multiple  interrupts  arc  required. 

To  transmit  a  packet,  successive  16-bit  words  of  the  packet  are  written  into  die  outgoing 
packet  buffer.  The  last  word  to  be  written  is  the  cable  address  of  the  destination  of  the  packet, 
or  0  to  broadcast  it.  The  hardware  is  then  told  to  initiate  transmission.  It  waits  until  the  cable  is 
not  busy  and  this  node’s  turn  to  transmit  arrives,  then  shifts  the  packet  out  onto  the  cable.  At 
the  completion  of  transmission  transmit-donc  is  set  and  tire  computer  is  interrupted.  If 
transmission  is  aborted  by  a  collision,  transmit-donc  and  transit! it-abort  are  set  and  the  computer 
is  interrupted.  As  the  packet  is  written  into  the  outgoing  packet  buffer,  a  16-bit  cyclic  redundancy 
checksum  is  computed  by  the  hardware.  This  checksum  is  transmitted  with  the  packet  and 
checked  by  the  receiver. 

To  receive  a  packet,  tire  clcar-rcccivcr  bit  is  asserted  by  the  program.  The  next  packet  on  the 
cable  which  is  addressed  to  this  node,  or  is  broadcast,  will  be  stored  into  the  incoming  packet 
buffer.  After  the  packet  has  been  stored,  the  computer  is  interrupted.  The  packet  buffer  will 
then  not  be  changed  until  the  next  dear- receiver  operation  is  performed,  giving  the  computer  a 
chance  to  read  out  the  packet.  If  a  packet  appears  on  the  cable  addressed  to  this  node  while  the 
incoming  packet  buffer  is  busy,  a  collision  is  simulated  so  as  to  abort  the  transmission.  As  a 
packet  is  stored  into  the  incoming  packet  buffer,  the  16-bit  cyclic  redundancy  checksum  is 
checked,  and  it  is  checked  again  as  the  packet  is  read  out  of  the  packet  buffer.  This  provides  full 
checking  for  errors  in  the  network  and  in  the  packet  buffers. 

'flic  standard  interrupt-vector  address  for  the  Chaosnet  interface  is  270.  The  standard  interrupt 
priority  level  is  5.  The  standard  Unibus  address  is  764140.  These  arc  the  device  registers: 

764140  Communit/ Status  Register 

This  register  contains  a  number  of  bits,  in  the  usual  pdpll  style.  All  rend/write  bits  are 
initialized  to  zero  on  power-up.  Identified  by  their  masks,  these  are: 

1  Timer  Interrupt  I  suable  (read/write).  I  enables  interrupts  from  the  interval  timer 
present  in  some  versions  of  the  interface  (not  described  here). 

Z  loop  hack  (read/wrile).  If  this  bit  is  1.  the  cable  and  transceiver  are  not  used 
and  the  interlace  is  looped  back  to  itself.  This  is  for  maintenance. 

4  Spy  (read/wrile).  If  this  hit  is  1,  the  inieifnce  will  receive  all  packets  regardless 
of  their  destination,  ibis  is  for  maintenance  and  network  monitoring. 

10  Clear  Receiver  (wiitc  only).  Writing  a  1  into  this  bit  clears  Receive  Done  and 
enables  the  receivci  to  receive  another  packet. 

?0  Receive  Interrupt  Ituhle  (read/wrile).  II  Receive  Done  and  Recce  e  Interrupt 
Tn.il'lc  aic  boil)  I.  the  iompnu  i  i>  intcriuplcd. 
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764142 

764144 

764146 

764152 


40  Transmit  Interrupt  finable  (rcad/writc).  if  Transmit  Done  and  Transmit 
Interrupt  finable  arc  both  1,  the  computer  is  interrupted. 

100  Transmit  Abort  (read  only).  This  bit  is  1  if  the  last  transmission  was  aborted, 
by  a  collision  or  because  the  receiver  was  busy. 

200  'Transmit  Done  (read  only).  This  bit  is  set  to  1  when  a  transmission  is 
completed  or  aborted,  and  cleared  to  0  when  a  word  is  written  into  die  outgoing 
packet  buffer. 

400  Clear  Transmitter  (write  only).  Writing  a  1  into  this  bit  stops  the  transmitter 
and  sets  'Transmit  Done.  'This  is  for  maintenance. 

17000  Lost  Count  (read  only).  These  4  bits  contain  a  count  of  the  number  of  packets 
which  would  have  been  received  if  the  incoming  packet  buffer  had  not  been 
busy.  Setting  Clear  Receiver  resets  die  lost  count  to  0. 

20000  Reset  (write  only).  Writing  a  1  into  this  bit  completely  resets  the  interface,  just 
as  at  power  up  and  Unibus  Initialize. 

40000  CRC  Hrror  (read  only).  If  this  bit  is  1  the  receiver’s  cyclic  redundancy 
checksum  indicates  an  error.  This  bit  is  only  valid  at  two  times:  when  the 
incoming  packet  buffer  contains  a  fresh  packet,  and  when  die  packet  has  been 
completely  read  out  of  the  packet  buffer. 

100000  Receive  Done  (read  only).  A  1  in  this  bit  indicates  that  the  incoming  packet 
buffer  contains  a  packet. 

My  Address  (read) 

Reading  this  location  returns  the  network  address  of  this  interface  (which  is  contained  in  a 
set  of  DIP  switches  on  the  board). 

Write  Buffer  (write) 

Writing  diis  location  writes  a  word  into  the  outgoing  packet  buffer.  The  last  word  written 
is  the  destination  address. 

Read  Buffer  (read  only) 

Reading  this  location  reads  a  word  from  the  incoming  packet  buffer.  The  last  three  words 
read  arc  the  destination  address,  the  source  address,  and  die  checksum. 

Bit  Count  (readonly) 

This  location  contains  the  number  of  bits  in  the  incoming  packet  buffer,  minus  one. 
After  the  whole  packet  has  been  read  out,  it  will  contain  7777  (a  12-bit  minus-one). 

Start  Tniiisini'.sion  only) 

Reading  this  location  initiates  transmission  of  the  packet  in  the  outgoing  packet  buffer. 

I  lie  value  lead  is  the  network  address  of  this  interlace.  This  method  for  starting 
transmission  may  seem  strange,  but  it  makes  it  easier  for  the  hardware  to  gel  the  source 
address  into  the  packet. 


I  >SK  :MO<  AM  f!l  li  10/ 


15  If  iN  SI 


Chaosnet  37  The  ITS  Implementation 

8.  The  ITS  Implementation 

8.1  System  Calls 

Note  that  the  NETWRK  subroutine  package,  page  42,  provides  a  convenient  interface  to  most 
of  these  system  calls  for  the  assembly-language  programmer. 

8.1.1  Opening  I/O  Channels 

Since  ITS  I/O  Channels  arc  unidirectional,  a  Chaosnet  connection  is  represented  by  a  pair  of 
channels,  one  for  input  and  one  for  output.  Operations  that  arc  not  inherently  directional,  such 
as  finding  out  the  state  of  the  connection,  may  be  done  on  cither  channel  (it  makes  no 
difference). 

Unlike  every  other  device,  you  do  not  obtain  these  channels  with  the  OPEN  system  call. 
Instead  a  special  system  call,  CHAOSO,  is  provided.  This  docs  not  open  a  connection;  it  simply 
gives  you  a  pair  of  channels  and  a  potential  connection,  in  the  Closed  suite,  which  can  be  opened 
by  transmitting  a  packet  (an  RFC  for  instance)  through  the  output  channel. 

CHAOSO  takes  three  arguments:  the  input  channel  number,  the  output  channel  number,  and 
the  receive  window  size.  If  cither  channel  is  currently  open  it  is  closed  first  (just  as  with  OPEN). 
CHAOSO  returns  no  values.  Error  6  (device  full)  is  signalled  if  the  system’s  connection  table  is 
full. 

8.1.2  Input  und  Output 

Input  and  output  can  be  done  on  a  Chaosnet  connection  in  terms  of  cither  packets  or  8-bit 
bytes.  8-bit  byte  I/O  is  usually  done  with  the  SIOT  system  call;  the  IOT  system  call  or  the  .IOT 
uuo  may  also  be  used— the  channel  behaves  as  if  it  had  been  opened  in  unit  mode.  8-bit  byte 
output  is  collected  by  the  system  into  packets  containing  the  maximum  allowed  number  of  bytes; 
when  a  packet  is  full  it  is  transmitted  with  the  standard  data  opcode  (200).  Until  a  full  packet’s 
worth  of  bytes  have  been  output  nothing  will  be  transmitted  unless  the  FORCE  system  call  is 
used.  8-bit  input  comes  from  packets  with  the  data  opcode  (200).  If  an  I  OF  packet  is  received, 
the  standard  cnd-uf-file  behavior  will  occur— IOT  will  return  the  EOF  character  (-1„3)  and  SIOT 
will  return  with  a  non-zero  residual  byte  count.  If  some  other  kind  of  packet  is  received,  an  10(3 
error  will  be  signalled  (sec  below).  If  PKTIOT  (see  below)  is  used  to  read  out  a  non-data  packet, 
stream  input  may  be  continued  past  it. 

Hit  1.4  in  the  control  bits  is  "don't  hang"  mode  for  both  input  and  output.  When  SIOT  is 
done  with  this  bit  specified,  and  no  input  is  available  or  (lie  output  window  is  full,  it  will  simply 
return  without  (runsfoiriiig  the  full  number  of  bytes  specified.  The  byte-pointer  and  byte-count 
arguments  to  SIOT  aie  updated  past  the  bytes  that  were  transferred.  When  input  IOT  is  dime  in 
"don't  linnr"  mode,  and  no  input  is  a\  ul  able.  the  I  ()l  character  (-1,3)  is  returned.  Output  IOT 
should  not  be  done  in  "don't  hang”  mode  since  it  lias  no  way  to  indicate  that  it  did  not  transmit 
anything.  If  i  non  d  ii.i  packet  is  icici.ctl  "don'i  hang"  mode  will  behave  the  same  as  if  there 
was  no  inpui  available. 
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Before  doing  8-bit  byte  I/O,  the  user  program  must  open  a  Chaosnet  stream  connection  by 
transmitting  and  receiving  the  appropriate  RFC,  LSN,  or  OPN  packets  and  following  the  protocol 
described  on  page  21.  The  NETWRK  subroutine  package  can  be  useful  for  this. 

Input  and  output  can  be  done  in  terms  of  packets  by  using  the  PKTIOT  system  call,  l  he  first 
argument  is  the  I/O  channel  number  and  the  second  is  the  address  of  the  packet  to  be 
transmitted  or  of  a  126.-word  buffer  to  contain  the  packet  to  be  received.  No  values  arc  returned. 

Input  PKTIOT  will  return  data  packets  and  the  following  types  of  control  packets:  RFC, 
OPN,  FWI),  ANS,  Cl.S,  LOS,  HOF',  and  UNC.  The  other  types  of  control  packets  arc  for  the 
NCP's  internal  use  only.  If  no  input  packets  arc  available,  PKTIOT  will  wait.  If  the  connection 
is  in  a  bad  state,  an  IOC  error  will  be  signalled.  This  is  discussed  in  the  next  section. 

Output  PKTIOT  will  accept  data  packets  and  CHS,  HOF,  and  UNC  packets  if  the  connection 
is  open.  Transmitting  an  UNC  packet  when  the  connection  is  closed  puts  it  into  the  Foreign 
Protocol  state.  RFC,  LSN,  OPN,  FWD,  and  ANS  packets  may  be  transmitted  if  the  connection 
is  in  the  appropriate  state.  Transmitting  a  bad  packet  type  or  transmitting  when  the  connection  is 
in  the  wrong  state  signals  an  IOC  error  (see  the  next  section).  Normally  the  user  sets  only  the 
opcode  and  number  of  bytes  fields  in  die  packet  header;  PKTIOT  fills  in  die  rest.  When  sending 
an  RF'C,  the  user  specifics  the  destination-host  field  and  the  system  remembers  it.  When  sending 

an  UNC,  the  user  specifies  everything  but  the  source  host  and  index. 

Note  that  PKTIOT  docs  not  synchronize  with  8-bit  byte  I/O.  If  a  partial  packet’s  worth  of 
bytes  have  been  output,  and  then  a  packet  is  output  with  PKTIOT,  that  packet  will  get  ahead  of 
those  bytes.  The  FORCE  system  call  can  be  used  to  change  this.  If  a  partial  packet's  worth  of 
bytes  have  been  input,  and  then  a  PKTIOT  is  done,  diosc  bytes  will  remain  available  to  the 
stream  and  PKTIOT  will  read  the  next  packet  after  them. 

8.1.3  Interrupts 

I/O  (second-word)  interrupts  occur  if  enabled  when  an  I/O  operation  formerly  would  have 
hung  but  now  will  not.  In  other  words,  an  interrupt  occurs  on  the  input  channel  when  a  packet 

arrives  while  dicrc  arc  no  input  packets  available,  if  die  packet  is  of  a  type  that  input  PKTIOT 

would  return.  An  interrupt  occurs  on  the  output  channel  if  the  window  is  full  and  an 
acknowledgement  arrives  which  makes  some  space  in  the  window.  Completely  interrupt-driven 
I/O  can  easily  be  programmed  for  the  Chaosnet,  using  the  WHYINT  system  call  (see  below). 

An  interrupt  also  occurs  on  the  input  channel  when  the  connection  state  changes. 

A  %PIIOC  inlcriupt  (also  railed  an  "IOC  error")  incurs  if  any  of  a  variety  of  illegal 
operations  is  performed.  IOC  error  3  (non- recoverable  data  error)  is  signalled  if  a  packet  is 
transmitted  with  PKTIOT  and  it  lias  an  illegal  size  or  opcode  in  the  header.  IOC  error  12  octal 
(channel  in  illegal  mode)  is  signalled  if  byte  or  packet  input  or  output  is  done  with  the 
connection  in  the  wrong  suite,  or  if  byte  input  is  done  and  a  packet  other  than  a  normal  data 
par  Ket  or  I  Of  is  found. 
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8.1.4  Miscellaneous  Operations 

The  CLOSE  system  call,  or  the  .CLOSE  uuo,  may  be  used  to  close  the  I/O  channels  and  the 
connection.  When  both  channels  arc  closed,  all  buffers  and  other  information  associated  with  the 
connection  arc  immediately  discarded.  If  the  connection  is  open  a  CLS  packet  is  transmitted. 
You  can  also  transmit  a  CI  S  yourself,  with  an  explanatory  message  in  it,  before  doing  the 
CLOSE. 

The  FORCE  system  call,  or  the  .NETS  uuo,  can  be  used  on  an  output  channel.  If  there  is 
buffer  containing  a  partial  packet’s  worth  of  8-bit  byte  output,  it  is  transmitted  as  a  packet  of  less 
than  the  maximum  size. 

The  FINISH  system  call  first  does  a  FORCE  and  then  waits  for  all  packets  that  have  been 
transmitted  to  be  acknowledged. 

The  RESET  system  call,  and  die  .RESET  uuo,  are  ignored,  as  on  most  devices.  The  RCHST 
and  RFNAME  system  calls,  and  the  .RCHST  uuo,  return  die  standard  information  for  a  non-file 
device,  with  device-name  CHAOS:.  No  device-dependent  information  is  returned. 

The  WHY1NT  system  call,  given  either  the  input  channel  or  the  output  channel  of  a  Chaosnet 
connection,  returns  a  lot  of  useful  device-dependent  information  about  the  connection: 

val  1  T  he  device  code,  which  is  the  value  of  die  symbol  %WYCHA. 

val  2  The  state  of  the  connection.  Symbols  for  the  connection  states  start  with  die  prefix  %CS: 
%CSCLS  Closed  (or  never  opened). 

%CSLSN  Listening  for  an  incoming  RFC. 

%CSRFC  RFC  received  while  listening;  neither  accepted  nor  rejected  yet. 

%CSRFS  RFC  sent,  awaiting  acceptance,  rejection,  or  answer. 

%CSOPN  Open. 

%CSLOS  Broken  by  receipt  of  a  I  . OS  packet. 

%CSINC  Broken  by  "incomplete  transmission"  (no  response  from  foreign  host  for  a 
long  time). 

%CSFRN  Using  a  foreign  protocol,  encapsulated  in  UNC  packets. 

val  3  T  he  left  half  is  the  number  of  available  input  packets.  T  his  docs  not  count  out-of-order 
packets.  Ibis  number  is  increased  by  one  if  there  is  buffered  input  available  for  8-bit 
byte  input.  T  his  number  is  zero  if  the  Chaosnet  connection  is  directly  connected  to  a 
STY  (sec  STYNET). 

The  right  half  is  the  number  of  output  packets  which  have  not  yet  been  acknowledged 
and  hence  are  occupying  space  in  the  window. 

val  4  The  left  half  is  the  receive  window  M/e  and  the  right  half  is  the  transmit  window  si/e. 

val  5  The  left  half  is  the  input  i h.-mio-l  number  and  the  light  half  is  the  output  channel 
number.  I  lice  numheis  ate  -I  d  die  channel  lias  been  Cl  Ofil  d  or  IOPUSI  led. 
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The  NETBLK  system  call  works  similarly  on  the  Chaosnet  as  on  the  Arpanet.  The  first 
argument  is  a  channel  number  (input  or  output).  The  second  argument  is  a  connection  state  code. 
The  third  argument,  which  is  optional,  is  a  timeout  in  30ths  of  a  second.  If  it  is  not  immediate 
it  is  modified.  NETBLK  hangs  until  the  connection  state  is  different  from  the  specified  state  or 
the  timeout  (if  specified)  elapses.  Two  values  arc  returned:  the  current  state  of  the  connection 
and  the  amount  of  time  left 

The  STYNET  system  call  works  similarly  on  the  Chaosnet  as  on  the  Arpanet.  It  allows  a 
Chaosnet  connection  and  a  SIT  (pseudo  terminal)  to  be  connected  together  so  that  a 
Tclnct/Supdup  server  program  can  provide  efficient  service.  1'hc  arguments  arc: 

arg  1  The  STY  channel  number. 

arg2  'The  Chaosnet  input  channel  number  to  connect  it  to,  or  -1  to  disconnect  it. 

arg  3  'rhe  Chaosnet  output  channel  number.  This  is  not  actually  used  on  the  Chaosnet. 

arg 4  Up  to  three  8-bit  characters,  left-justified,  to  be  transmitted  when  an  output-reset  is  done 

on  the  terminal.  These  characters  arc  protocol-dependent.  If  any  unusual  condition 
occurs,  including  input  of  a  byte  with  the  high-order  bit  on  from  the  network,  the  STY 
will  be  disconnected  from  the  Chaosnet  channel  and  the  user  will  be  interrupted.  It  is 
illegal  to  do  I/O  on  any  of  the  involved  channels  without  disconnecting  them  from  each 
other  first 

The  CHAOSQ  system  call  allows  the  ATSIGN  CHAOS  program,  described  below,  to  peek  at 
the  queue  of  pending  RFC’s.  It  takes  one  argument,  which  is  the  address  of  a  126-word  buffer. 
The  first  RFC  packet  on  the  queue  is  copied  into  this  buffer  and  moved  to  the  end  of  the  queue. 
If  the  queue  is  empty,  the  system  call  takes  the  error  return. 

8.2  Utility  Programs 

The  K  mode  in  the  :PEEK  command  gives  one  line  of  information  for  each  Chaosnet 
connection  in  existence  on  die  local  machine,  lists  the  number  of  packet  buffers  in  existence  and 
free,  and  lists  any  queued  RFC’s  (sec  the  following  section).  Packet  buffers  arc  dynamically 
allocated  in  groups  of  8  from  system  memory.  Packet  buffers  in  existence  and  not  free  may  be  in 
use  to  contain  packets  being  transmitted  to  or  received  from  the  hardware,  unreceipted  output 
packets,  or  input  packets  not  yet  mad  by  the  user  program. 

The  information  about  a  Chaosnet  connection  printed  by  PEEK  consists  of: 

IDX  The  connection  index  number  (not  including  the  uniqui/ation  bits). 

USR  Hie  user  index  or  ITS  job  number  of  the  user  process  which  owns  the  connection. 

IJNAME 

JNfME  I  lie  name  of  the  user  process  which  owns  the  connection. 

STATE  The  stale  of  the  connection.  This  is  one  of  the  slates  listed  in  section  4.6,  page 

25.  abbreviated  to  six  characters.  IOWI.VI  means  the  foreign  piotocol  state. 

IBF  1  lie  number  of  input  packets  buffered  and  available  to  be  lead  by  the  user 

process. 

PHI  I  lie  number  of  input  pac  kets  buffered  but  not  vet  available  to  the  user  process 

because  they  arc  out  of  order.  Some  eailici  pickets  are  missing;  when  they  arrive 
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these  packets  will  become  available. 

NOS  The  number  of  output  "slots"  available  in  the  window.  The  user  process  may 

send  this  many  packets  before  it  will  have  to  wait  for  an  acknowledgement. 

ACK  The  number  of  received  packets  which  should  be  acknowledged  but  which  have 

not  yet  been.  This  will  not  stay  non  zero  for  more  than  a  half  second,  since  if  it 
is  non  zero  an  S'l’S  will  be  transmitted. 

R  WIN  The  window  size  for  the  incoming  half  of  this  connection. 

WIN  T  The  window  size  for  the  outgoing  half  of  this  connection. 

FOREIGN  ADDR 

'I'hc  host  name  and  index  number  of  the  other  end  of  this  connection.  The  = 
command  switches  between  host  names  and  host  numbers. 

FLAG  One  or  more  single-letter  flags  indicating  special  things  about  the  connection.  The 

following  flags  exist: 

C  The  connection  is  half-closed  (one  of  its  I/O  channels  has  been  closed  and 
the  other  remains  open). 

F  The  connection  is  turned  "off"  as  far  as  the  interrupt  side  of  die  NCP  is 
concerned.  No  packets  will  be  received  or  transmitted. 

1  The  connection  has  an  input  buffer  for  stream  (non-packet)  input. 

O  The  connection  has  an  output  buffer  for  stream  (non-packet)  output. 

S  An  STS  packet  needs  to  be  sent. 

T  The  connection  is  connected  to  a  STY.  In  other  words  it  is  an  incoming 

Telnet  or  Supdup  connection  and  the  system  is  providing  the  data  transfer 

between  the  connection  and  the  pseudo  terminal. 

The  :CHASTA  command  is  a  long-winded  version  of  the  above.  It  prints  several  lines  of 
information  about  each  connection  that  exists,  including  the  number  of  the  next  packet  to  be 
given  to  the  user,  die  number  of  the  next  packet  to  be  output  by  die  user,  and  the  number  of 
the  last  packet  acknowledged  in  each  direction. 

I'hc  :CHARFC  command,  given  a  host  name  and  a  contact  name  in  the  command  line,  will 

open  a  connection  and  print  whatever  comes  back  (refusal,  simple  transaction,  or  any  data  that 

emerge  from  a  stream  connection).  The  contact  name  may  of  course  be  followed  by  a  space  and 
arguments.  This  command  can  be  useful  in  connection  with  the  STATUS  protocol,  to  sec  if  a 
host  is  up  (it  will  print  its  name  followed  by  some  garbage  characters),  and  in  connection  with 
the  PULSAR  protocol,  to  turn  pulsars  on  and  olf. 

The  :CHATST  command  provides  a  v.uicty  of  simple  Chaosnet  manipulating  commands.  Run 
it  and  type  ?  for  a  list  of  the  commands.  I  he  II  (host. it)  command  may  be  the  most  useful;  it 
uses  the  STATUS  protocol  to  get  mclciing  information  from  a  host  and  prints  it  nicely. 

The  :HOST  command  given  the  name  of  a  host  in  lliiScoinin.ind  line,  looks  up  that  host  in 
the  system  host  table  ami  prints  what  is  Inov.n  about  it.  uNJmlim;  Us  mimetic  .nl.lie,y  Ibis 
works  lor  hosts  on  II  uclwoiks  I  he  .(  IIAlAli  tuiumuiKl  piiiXs  a  table  of  all  the  hosts  on 
Chaosnet.  X 
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8.3  Server  Programs 

When  an  RFC  is  received  for  a  contact  name  for  which  there  is  no  outstanding  LSN,  the 
RFC  packet  is  saved  on  a  pcnding-RFC  queue  and  a  new  process  is  created  and  made  to  run  the 
program  in  the  file  SYS:ATSIGN  CHAOS,  This  program  uses  the  CHAOSO  system  call  to  find 
out  the  contact  name  of  the  RFC.  The  contact  name  name  is.  truncated  to  six  characters  if  it  is 
longer.  If  a  file  named  DSK:DEVICE;CHAOS  name  exists,  that  file  contains  the  desired  server 
program;  it  is  loaded  into  the  server  process.  When  the  server  process  is  started,  register  0 
contains  the  contact  name  in  sixbit  and  channel  1  is  still  open  to  the  program  file.  The  server 
program  must  do  a  listen  for  its  contact  name,  open  die  connection,  log  in,  and  so  forth. 

Thus  a  server  for  a  new  protocol  can  be  added  simply  by  putting  a  link  on  the  DEVICE 
directory.  This  directory  is  also  used  for  Arpanet  servers  and  for  ITS  I/O  device  servers. 

If  no  file  is  found,  a  file  named  DSK:DEVICE;CHAOS  DFAULT  is  loaded  if  it  exists.  If  it 
does  not  exist  cither  (which  is  normally  the  ease)  the  RFC  is  ignored  and  the  server  process  kills 
itself.  After  a  while  the  system  will  refuse  the  RFC  by  sending  back  a  CI.S  unless  someone 
comes  along  and  listens  for  it. 

8.4  Subroutine  Packages 

'Hie  file  SYSTEM;CHSDEF  >  can  be  .INSRT’cd  into  a  Midas  program  to  define  symbols  for 
die  format  of  a  packet,  die  packet  opcodes,  and  die  states  of  a  connection.  The  symbol  prefixes 
arc  %CO  for  opcodes,  %CS  for  states,  $CPK  for  packet-format  byte-pointers,  and  %CP  for 
packet-format  values. 

The  file  SYSENG;NETWRK  >  can  be  .INSRT’cd  into  a  Midas  program  to  provide  a  library  of 
subroutines  for  opening  connections,  listening  for  requests  for  connection,  analyzing  network 
errors  and  printing  useful  messages  to  the  user,  and  accessing  the  host-name  table 
(SYSBIN;HOSTS2).  All  system  programs  that  use  the  Chaosnet  do  so  with  the  aid  of  these 
subroutines.  NETWRK  supports  both  Chaosnet  and  Arpanet.  Documentation  is  provided  in 
omments  at  the  beginning  of  the  file. 
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9.  The  TOPS-20/TENEX  Implementation 

A  Chaosnet  connection  is  represented  by  a  JFN  obtained  from  die  CHA:  device.  The 
standard  I/O  operations  can  be  performed  on  such  a  JFN,  in  which  case  the  system  will  open  a 
Chaosnet  stream  connection  and  transfer  8-bit  bytes  in  both  directions.  When  a  Chaosnet 
connection  is  used  in  this  way.  it  is  compatible  with  the  rest  of  the  TOPS-20  file  and  I/O  system. 

Alternatively,  special  operations  can  be  used  to  send  and  receive  packets  and  do  other 
Chaosnet-specific  operations  on  a  Chaosnet  JFN.  These  arc  described  below. 

For  more  information,  see  [CPR], 


9.1  Opening  Connections 

A  (potential)  Chaosnet  connection  is  represented  by  a  JFN.  When  the  JFN  is  opened,  an 
actual  Chaosnet  connection  is  created.  The  GTJFN  syntax  is  as  follows: 

The  device  name  is  CHA:.  The  filename  is  the  symbolic  name  or  octal  number  of  the  host  at 
the  other  end  of  the  connection,  or  a  null  string  if  it  is  desired  to  listen  for  an  incoming  Request 
For  Connection  rather  than  initiating  a  connection.  The  extension  (filctype)  is  normally  the 
contact  name;  some  special  cases  arc  described  below.  Use  of  *  names  and  JFN  stepping  is  not 
permitted.  The  directory,  generation  (version)  number,  and  semicolon  attributes  arc  ignored  if 
present. 

When  the  JFN  is  opened  (with  OPENF),  normally  the  system  will  wait  for  the  connection  to 
open  up;  a  user  connection  (nonblank  filename)  will  wait  for  a  response  to  be  returned  to  its 
RFC,  and  a  server  connection  (blank  filename)  will  wait  for  an  RFC  to  come  in  to  its  contact 
name.  If  an  RFC  is  refused  or  the  foreign  host  is  not  up,  OPENF  will  return  an  error.  If  data 
mode  6  or  7  is  used  with  OPENF,  it  will  return  immediately,  without  waiting  for  the  connection 
to  open.  This  is  useful  if  you  want  to  open  several  Chaosnet  connections  simultaneously,  or  if 
you  want  to  determine  the  reason  for  failure  if  the  connection  does  not  open;  if  live  normal  data 
mode  0  OPF.NF  fails,  the  operating  system  will  not  let  you  read  the  CLS  packet  nor  do  the 
•MOERR  operation  (described  below). 

There  arc  a  number  of  special  cases  in  the  GTJFN  syntax.  If  the  extension  is  a  null  string, 
then  the  contact  name  is  specified  by  OPENF  rather  than  by  GTJFN;  AC3  contains  die  number 
of  characters  in  the  contact  name  in  the  left  half,  and  the  address  of  tire  contact  name  in  tire 
right  half.  In  listening  mode  (the  filename  is  a  null  string),  then  if  the  extension  is  also  null,  this 
JFN  will  listen  to  any  RFC  that  is  not  otherwise  serviced.  Privileges  are  required  and  only  one 
job  at  a  time  can  do  this.  This  mechanism  is  used  by  a  system  server  process.  If  the  filename  is 
null  and  the  extension  is  a  hyphen,  the  JFN  is  put  in  a  special  mode  for  simple  transactions; 
packct-lcvcl  I/O  may  be  used  to  transmit  any  number  of  RFC’s  and  receive  any  response  packets 
(ANS,  FWI ),  I  .OS,  or  CIS). 

When  a  JFN  is  Hosed  with  CLOSr,  if  it  has  an  open  conneetion  the  end  ofdata  protocol  is 
used  (an  TOP  packet  is  transmitted  and  >ls  acknowledgement  is  awaited),  and  then  it  CIS  packet 
is  tun- .milted.  (  IIik  is  not  completely  implemented  vet;  uiircntly  no  I  OF  is  sent,  and  MOEOF 
(\'v  below)  mut  he  used.)  It  the  JIN  is  in  the  I  *  Ft  Keiehed  stale,  the  Kit  is  o  fused  by 
sending  a  Cl  S. 
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9.2  Stream  Input  and  Output 

The  normal  I/O  JSYSes  (BIN,  BOUT,  SIN,  SOUT)  work  on  Chaosnet  JFN$.  When  the 
connection  was  created  by  listening,  doing  I/O  to  it  automatically  accepts  it  first  (sending  an 
OPN).  'Hie  input  and  output  data  arc  transmitted  as  8-bit  bytes  in  standard  data  packets  (opcode 
200).  On  input,  if  an  HOF  packet  is  encountered  the  standard  end-of-file  action  occurs.  If  a  CLS 
or  I.OS  is  encountered,  or  the  connection  is  in  a  bad  suite,  an  error  is  signalled.  ITic  message 
from  the  CHS  or  LOS  may  be  picked  up  with  .MOERR  (see  below). 

On  TOPS-20.  but  not  Tcncx,  the  SIBE,  SOBE,  DIBE,  DOBE,  SINR,  and  SOUTR  JSYSes 
may  be  used.  The  latter  two  treat  each  packet  as  a  separate  record. 

The  OPENF  byte  size  may  be  cither  7  or  8.  With  a  byte  size  of  8,  the  raw  Chaosnet  data 
bytes  are  transmitted.  With  a  byte  size  of  7,  the  system  converts  between  the  ASCII  code  it  uses 
normally  and  the  Lisp  Machine  character  set,  which  is  standard  on  Chaosnet.  (This  is  not  yet 
implemented;  currently  a  byte  size  of  7  will  be  accepted  but  will  behave  the  same  as  8.) 

9.3  Packet  Input  and  Output 

It  is  possible  to  do  packet-level  input  and  output  and  to  deal  directly  with  the  details  of  the 
Chaosnet  protocol  by  using  the  special  operations  described  in  the  following  section.  Note  that 
stream  I/O  and  packet  I/O  should  not  be  mixed  in  the  same  connection,  unless  you  know  exactly 
what  you  are  doing,  since  you  can  get  your  data  out  of  order. 


9.4  Special  Operations 


GDSTS  returns  device-dependent  status.  AC2  returns  the  state  of  the  connection,  and  AC3 
returns  the  number  of  packet  slots  available  in  the  output  window  in  the  left  half,  and  the 
number  of  available  input  packets  in  the  right  half.  The  symbolic  names  for  the  connection  states 
arc  as  follows: 


.CSCLS  'ITic  connection  is  closed  (or  was  never  opened). 

CSLSN  The  connection  is  listening  for  an  RFC. 

.CSRFC  An  RFC  has  been  received  by  a  listening  connection. 

C3RFS  An  RFC  has  been  sent. 

.CSOPN  The  connection  is  open. 

.CSLOS  The  connection  has  been  broken  by  a  LOS  packet. 

.CSINC  The  connection  has  been  broken  by  Incomplete  Transmission  (no  response  from 

the  other  end  for  a  long  time). 

.CSPRF  This  is  the  "permanent  RFC"  stale  which  is  entered  by  GTJFN  with  a  null 
filename  and  an  ex  tension  of  just  a  hyphen. 


MTOPR  performs  a  variety  of  special  operations,  with  the  JfN  in  ACl,  one  of  the  following 
Iniutioo  codes  in  AC?,  and  an  arpinnenl  and/or  lelurn  value  in  AC3. 

Send  a  packet.  AC3  contains  the  address  of  the  fust  word  of  the  packet.  An 
enor  return  is  taken  if  the  connection  is  in  a  had  slate  for  the  kind  of  packet 
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.MOPKR 

.MOOPN 

.MOSND 

.MOEOF 

.MONOP 

.MOERR 


.MOACN 


.MOSWS 

.MORWS 

.MOAWS 

.MOUAC 

.MOFHS 

MOSIZ 

.MOSRT 


being  transmitted.  This  will  wait  for  space  to  be  available  in  the  window. 

Receive  a  packet.  AC3  contains  the  address  of  a  126-word  buffer  in  which  the 
packet  is  to  be  stored.  This  will  wait  until  an  input  packet  arrives. 

Accept  a  Request  for  Connection.  Error  if  the  connection  is  not  in  the  RFC- 
received  state. 

Force  out  any  buffered  stream  output. 

Force  out  any  buffered  stream  output,  then  send  an  EOF  packet. 

Force  out-  any  buffered  stream  output,  then  wait  for  it  to  be  transmitted  and 
acknowledged.  ('Phis  is  not  a  "no  op",  but  .MONOP  is  the  system  standard  name 
for  this  operation.) 

Returns  the  error  message  from  a  received  CLS  or  I.OS  packet.  An  error  is 
signalled  if  no  error  message  is  available.  AC3  is  u  string  pointer  to  where  to  put 
the  error  message:  it  is  updated  to  point  at  the  terminating  null  character  which 
makes  the  message  an  ASCI/,  string. 

Assigns  PSI  (interrupt)  channels.  The  left  half  of  AC3  is  the  channel  number  for 
output  interrupts,  and  die  right  half  is  the  channel  number  for  input  and  state- 
change  interrupts.  Specifying  -1  as  a  channel  number  disables  interrupts.  Output 
interrupts  arc  signalled  when  the  window  is  full  and  then  an  acknowledgement  is 
received  which  makes  some  space  so  that  more  packets  may  be  output.  Input 
interrupts  arc  signalled  when  die  suite  changes,  and  when  there  arc  no  input 
packets  available  and  then  a  packet  is  received. 

Sets  the  receive  window  size  from  AC3. 

Returns  the  receive  window  size  in  the  left  half  of  AC3  and  the  transmit  window 
size  in  the  right  half. 

Returns  the  available  space  in  the  transmit  window  in  AC3. 

Returns  the  number  of  unacknowledged  output  packets  in  AC3. 

Returns  the  foreign  host  number  in  AC3. 

Returns  the  maximum  packet  size  in  bytes  in  AC3.  This  can  be  smaller  than  the 
Chaosnet  standard  (488)  on  machines  encumbered  with  an  KSX20F  front  end. 

Sets  the  RFC  timeout  period  in  milliseconds  from  AC3.  The  maximum  is  262 
seconds. 


9.5  Utility  Programs 

There  are  two  Chaosnet  utility  programs,  both  named  CHASTA.  One  prints  one  line  for  each 
connection  that  exists,  giving  its  stale,  number  of  input  and  output  packets,  who  it  is  connected 
to,  etc.  The  other  prints  the  STATUS  protocol  information  for  every  host  on  the  network, 
including  the  host  name,  when  it  was  last  tip,  and  its  packet  throughput  and  enor  c< unis,  this 
information  is  maintained  hy  a  system  daemon  pmcess. 
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9.6  Server  Programs 

When  an  RFC  is  received  for  contact-name ,  if  no  process  is  listening  for  contact-name  and 
the  file  SYSTEM:CHAOS.<wi/ac7-wwMe  (or  DSK:<SYSTEM>CHAOS.co/i/flc/-nfl»je  on  Tcncx)  exists, 
the  server  program  contained  in  that  file  is  run.  TTic  server  program  should  open  CH^:. contact- 
name.  This  is  implemented  by  the  CHARFC  program  which  runs  as  a  daemon  job  and  opens 
CHA:.,  the  magic  name  which  gets  a  copy  of  all  unclaimed  RFCs.  Normally  the  server  program 
is  run  in  a  freshly-created  job,  and  may  log  in  if  it  wishes,  but  if  the  file  is  marked  as  ephemeral 
(the  ";E"  attribute),  it  is  run  in  a  subfork  of  the  CHARFC  job.  Ephemeral  servers  should  be 
used  for  protocols  that  don’t  involve  a  long-term  connection. 

The  TELNET  and  SUPDUP  servers  attach  their  Chaosnet  connection  directly  to  an  NVT,  just 
as  the  corresponding  Arpanet  servers  do. 

When  the  system  starts  up.  the  file  SYSTEMiHOSTS2.BIN  (or  DSK:<SYSTEM>HOSTS2.BIN 
on  Tcncx)  is  read  in  and  used  to  initialize  the  host  name  table  inside  the  system  used  by  GTJFN. 
This  is  the  1TS/TOPS-20/ WAIT’S  standard  multi-network  host  table. 
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10.  The  Lisp  Machine  Implementation 

Lisp  Machine  Chaosnet  support  consists  of  a  set  of  Lisp  functions  and  data-structurc 
definitions  in  the  chaos:  package.  There  arc  three  important  data  structures.  A  conn  represents 
a  connection.  A  pkt  represents  a  packet.  A  stream  is  a  standard  I/O  stream  which  transmits  to 
and  receives  from  a  connection.  The  details  of  these  data  structures  arc  described  later. 

There  arc  two  processes  which  belong  to  the  Chaosnet  NCR.  The  receiver  process  looks  at 
packets  as  they  arrive  from  the  network.  Control  packets  arc  processed  immediately.  Data  packets 
arc  put  on  the  input  packet  queue  of  the  connection  to  which  they  are  directed.  The  background 
process  wakes  up  periodically  to  do  retransmission,  probing,  and  certain  "background  tasks"  such 
as  starting  up  a  server  when  an  RFC  arrives  and  processing  "connection  interrupts"  (described 
below). 

10.1  Opening  and  Closing  Connections 

10.1.1  User-Side 

chaos: connect  host  contact-name  &optional  window-size  timeout 

Opens  a  stream  connection,  and  returns  a  conn  if  it  succeeds  or  a  string  giving  the 
reason  for  failure,  host  may  be  a  number  or  the  name  of  a  known  host,  contact- name  is 
a  string  containing  the  contact  name  and  any  additional  arguments  to  go  in  die  RFC 
packet.  If  window-size  is  not  specified  it  defaults  to  13.  If  timeout  is  not  specified  it 
defaults  to  600  (ten  seconds). 

chaos: simple  host  contact- name  &oplional  timeout 

Taking  arguments  similar  to  those  of  chaos:cobnect,  this  performs  the  user  side  of  a 
simple-transaction.  The  returned  value  is  either  an  ANS  packet  or  a  string  containing  a 
failure  message.  The  ANS  packet  should  be  disposed  of  (using  chaos:return- pkt,  sec 
below)  when  you  arc  done  with  it. 

chaos : remove-conn  conn 

Makes  conn  null  and  void.  It  becomes  inactive,  all  its  hollered  packets  are  freed,  and  the 
corresponding  Chaosnet  connection  (if  any)  goes  away. 

chaos: close  conn  &opiional  reason 

Closes  and  removes  the  connection.  If  it  is  open,  a  Cl  S  packet  is  sent  containing  the 
string  reason.  Don’t  use  this  to  reject  RFC’s;  use  chaos:reject  for  that. 

chaos: open -foreign -connect Ion  host  index  ^optional  pki-allocation  distinguished-port 

Creates  a  conn  which  may  he  used  to  transmit  and  receive  foreign  protocols  encapsulated 
in  I  INC  p.'H'kcls.  host  and  index  are  the  destination  address  for  packets  sent  with 
ch:tos:snn<l  unc  pkt.  pki-alhmiiion  is  the  "window  si/e",  i.e.  the  maximum  number  of 
input  packets  wliuli  may  he  hiilknd.  Il  defaults  to  10.  It  Jistuniui'diid  pml  is  supplied, 
the  local  index  is  set  to  it.  this  is  noessaiy  to i  piotuuils  wln<  li  define  die  incininps  of 
pntieular  index  numbers 
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10.1.2  Server-Side 

chaos: listen  contact-name  &optional  window-size  wait- for- rfc 

Waits  for  an  RFC  for  the  specified  contact  name  to  arrive,  then  returns  a  conn  which 
will  be  in  the  RFC  Received  state.  If  window-size  is  not  specified  it  defaults  to  -13.  If 
wail-for-rfc  is  specified  as  nil  (it  defaults  to  t)  then  the  conn  will  be  returned  immediately 
without  waiting  for  an  RFC  to  arrive. 

chaos :server-a1 1st  Variable 

Contains  an  entry  for  each  server  which  always  exists.  When  an  RFC  arrives  for  one  of 
these  servers,  the  specified  form  is  evaluated  in  die  background  process;  typically  it 
creates  a  process  which  will  then  do  a  chaosdisten.  Use  the  add -initialization  function 
to  add  entries  to  this  list. 

chaos: accept  conn 

conn  must  be  in  the  RFC  Received  state.  An  ORN  packet  will  be  transmitted  and  conn 
will  enter  the  Open  state.  If  the  RFC  packet  has  not  already  been  read  with  chaos:get- 
next-pkt,  it  is  discarded.  You  should  read  it  before  accepting  if  it  contains  arguments  in 
addition  to  the  contact  name. 

chaos: reject  conn  reason 

conn  must  be  in  the  RFC  Received  state.  A  CLS  packet  containing  the  string  reason  will 
be  sent  and  conn  will  be  removed. 

chaos: answer-string  conn  string 

conn  must  be  in  the  RFC  Received  state.  An  ANS  packet  containing  the  string  string  will 
be  sent  and  conn  will  be  removed. 

chaos: answer  conn  pkt 

conn  must  be  in  the  RFC  Received  state,  pkt  is  transmitted  as  an  ANS  packet  and  conn 
is  removed.  Use  this  function  when  die  answer  is  some  binary  data  rather  dian  a  text 
string. 

chaos: fast-answer-string  contact-name  string 

If  a  pending  RFC  exists  to  contact-name,  an  ANS  containing  siring  is  sent  in  response  to 
it  and  t  is  returned.  Otherwise  nil  is  returned.  This  function  involves  the  minimum 
possible  overhead.  No  conn  is  created. 


10.2  Connection  States 
chaos: state  conn 

Returns  the  current  state  of  the  connection,  as  one  of  the  following  symbols: 

chaos.inactive -state  A  conn  which  docs  not  correspond  to  any  Chaosnet 

connection. 

chaomopen  -state  An  open  connection. 

chaos:rfc- sent -state  An  RFC'  has  been  transmitted  and  no  response  has  yet 

been  received. 
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chaos:answered -state 
chaos;cls  -  received  -  state 
chaos:  los  -  received  -  state 
chaos:host -down -state 

chaosdistening -state 

chaos:rfc  -  received  -  state 

chaos:foreign -state 


An  ANS  has  been  received. 

A  CI.S  has  been  received. 

A  I. OS  has  been  received. 

The  connection  is  in  the  Incomplete  Transmission  state; 
communications  with  the  foreign  host  have  broken  down. 

A  I.SN  has  been  "transmitted"  and  the  connection  is 
awaiting  an  RFC. 

An  RFC  has  been  received  while  listening  and  has  not  yet 
been  responded  to. 

The  connection  is  being  used  with  a  foreign  protocol 
encapsulated  in  UNC  packets. 


chaos: wait  conn  state  timeout  &optional  whostate 

Waits  until  the  state  of  conn  is  not  die  symbol  stale,  or  until  timeout  60ths  of  a  second 
have  elapsed.  If  the  timeout  occurs,  nil  is  returned;  otherwise  t  is  returned,  whostate  is 
the  process  state  to  put  in  the  who-linc;  it  defaults  to  "net  wait". 


10.3  Stream  Input  and  Output 

chaos: stream  conn 

Creates  a  bidirectional  stream  which  accesses  conn,  which  should  be  open  as  a  stream 

connection,  as  8-bit  bytes.  In  addition  to  the  usual  I/O  operations,  die  following  special 

operations  arc  supported: 

:force-output  Any  buffered  output  is  transmitted.  Normally  output  is  accumulated  until 
a  full  packet’s  worth  of  bytes  arc  available,  so  diat  maximum-size  packets 
arc  transmitted. 

:finish  Waits  until  cither  all  packets  have  been  sent  and  acknowledged,  or  the 

connection  ceases  to  be  open.  If  successful,  returns  t;  if  the  connection 
goes  into  a  bad  state,  returns  nil. 

:eof  Forces  out  any  buffered  output,  sends  an  HOF'  packet,  and  docs  a  .finish. 

:clear~eof  Allows  you  to  read  past  an  HOF  packet  on  input.  Ifacii  :tyi  will  return  nil 

or  signal  the  specified  cof  error  until  a  :clear-eof  is  done. 

:close  Send  a  CI.S  packet  and  remove  die  connection. 

10.4  Packet  Input  anil  Output 

Input  and  output  on  a  Chaosnet  connection  can  be  done  at  die  whole-packet  level,  using  the 
functions  in  this  section.  A  packet  is  repiesented  by  a  pkt  data  structure.  Allocation  of  pkts  is 
controlled  hv  the  system;  each  pkt  that  it  gives  you  must  be  given  back.  Theio  are  functions  to 
convert  between  plds  and  strings.  A  pkt  is  an  art  16h  array  containing  the  packet  header  and 
data:  the  chuosdiisl  data  word  in  pkt'ili  dement  of  the  array  is  tile  lirsi  16-bit  data  word.  The 
leader  of  a  pkt  contains  a  number  of  holds  med  by  die  system. 
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chaos :pkt-opcode  pkt 

Accessor  for  the  opcode  field  of  pkt' s  header.  For  each  standard  opcode  a  symbol  exists 
in  the  chaos:  package,  consisting  of  the  standard  3-lctter  code  and  a  suffix  of  "-op", 
chaos:rfc-op  for  example.  'Hie  value  of  the  symbol  is  the  numeric  opcode. 

chaos :pkt-nbyt«s  pkt 

Accessor  for  the  numbcr-of-data*bytcs  field  of  pkt's  header. 

chaos:pkt-str1ng  pkt 

An  indirect  array  which  is  the  data  field  of  pkt  as  a  string  of  8-bit  bytes.  I  hc  length  of 
this  string  is  equal  to  (chaos:pkt-nbytes  pkt). 

chaos  :sst-pkt-str1ng  pkt  &rcst  strings 

Copies  the  strings  into  the  data  field  of  pkt,  concatenating  them,  and  sets  (chaosipkt- 
nbytes  pkt)  accordingly. 

chaos :get-pkt 

Allocates  a  pkt  for  use  by  the  user. 

chaos : return-pkt  pkt 

Deallocates  a  pkt. 

chaos :  send-pkt  conn  pkt  &optional  (opcode chaos:dat-op) 

Transmits  pkt  on  conn,  pkt  should  have  been  allocated  with  chaos:get-pkt  and  then  had 
its  data  field  and  n-bytes  filled  in.  opcode  must  be  a  data  opcode  (200  or  more)  or  HOF. 
An  error  is  signalled,  with  condition  chaos:not-open-state.  if  conn  is  not  open. 

chaos ssend-atrlng  conn  &rcst  strings 

Sends  a  data  packet  containing  die  concatenation  of  strings  as  its  data. 

chaos :  send-unc-pkt  conn  pkt  &optional  pkt-nunibcr  ack-nwnber 

Transmits  pkt,  an  UNC  packet,  on  conn.  The  opcode,  packet  number,  and  acknowledge 
number  fields  in  die  packet  header  arc  filled  in  (the  latter  two  only  if  the  optional 
arguments  arc  supplied). 

chaos :may-transm1t  conn 

A  predicate  which  returns  t  if  there  is  any  space  in  the  window, 

chaos:  finish  conn  ^optional  (whostote  "Net  Finish") 

Waits  until  either  all  packets  have  been  sent  and  acknowledged,  or  the  connection  ceases 
to  be  open.  If  successful,  returns  t;  if  the  connection  goes  into  a  had  state,  returns  nil. 
ii hastate  is  the  process  state  to  display  in  (he  who  line  while  waiting. 

chaos : got-next-pkt  conn  ^optional  (no-lnnig-prii) 

Returns  the  next  input  packet  from  conn.  When  you  arc  done  with  the  packet  you  must 
give  it  hack  to  the  system  with  chaosvetum  pkt.  This  can  return  an  KIT,  f|  S.  or 
ANS  packet,  in  addition  to  data.  UNC.  <u  HOF.  If  no  Ining-p  is  t.  nil  will  Ire  letumed 
if  there  arc  no  packets  available  or  the  coi.iUrfion  is  in  a  had  state.  Otherwise  an  error 
will  he  signalled  it  the  louneclion  is  in  a  had  stale,  with  condition  name  oil  uv'/host- 
<lown.  chyusdos  received  stale,  or  chaomro  nl  on  dosod  connection.  II  no  packets 
ate  .nailable  and  no-lning  p  is  nil,  chaos:get  next -pkt  will  wait  lor  packets  to  come  in 
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or  the  state  to  change.  The  process  state  in  the  who-linc  is  "NETI’’. 

chaos.-data-avallable  conn 

A  predicate  which  returns  t  if  there  any  input  packets  available  from  conn. 

10.5  Connection  Interrupts 

chaos : Interrupt-function  conn 

This  attribute  of  a  conn  is  a  function  to  be  called  in  the  background  process  when  certain 
events  occur  on  this  connection.  Normally  this  is  nil,  which  means  not  to  call  any 
function,  but  you  can  use  setf  to  store  a  function  here.  Since  the  function  is  called  in 
the  Chaosnet  background  process,  it  should  not  do  any  operations  that  might  have  to  wait 
for  the  network,  since  that  could  permanently  hang  the  background  process. 

The  function’s  first  argument  is  one  of  the  following  symbols,  giving  the  reason  for  the 
"interrupt”.  The  function’s  second  argument  is  conn.  Additional  arguments  may  be 
present  depending  on  the  reason.  The  possible  reasons  are: 

.input  A  packet  has  arrived  for  the  connection  when  it  had  no  input  packets 

queued.  It  is  now  possible  to  do  chaos:get-next-pkt  without  having  to 
wait.  There  are  no  additional  arguments. 

:output  An  acknowledgement  has  arrived  for  the  connection  and  made  space  in 

the  window  when  formerly  it  full.  Additional  output  packets  may 
now  be  transmitted  with  chaos:send-pkt  without  having  to  wait.  Iherc 
arc  no  additional  arguments. 

:change- of -state 

The  state  of  the  connection  has  changed.  The  third  argument  to  the 
function  is  the  symbol  for  the  new  state. 

chaos : read-pkts  conn 

Some  interrupt  functions  will  want  to  look  at  the  queued  input  packets  of  a  connection 
when  they  get  a  :input  interrupt.  chaos:read-pkts  returns  the  first  packet  available  for 
reading.  Successive  packets  can  be  found  by  following  chaos:pkt-link. 

chaostpkt -link  pkt 

Lists  of  packets  in  the  NCR  arc  threaded  together  by  storing  each  packet  in  the 
chaos:pkt  link  of  its  predecessor.  The  list  is  terminated  with  nil. 


10.6  Information  and  Control 
chaos :host  data  &optional  host 

host  may  he  a  number  or  a  known  host  name,  and  defaults  to  the  local  host.  I  wo  values 
are  relumed.  The  first  value  is  (lie  host  name  and  the  second  is  the  host  number.  If  the 
host  is  a  number  not  in  the  table,  it  is  asked  its  name  using  the  STATUS  protocol:  if  no 
icsponse  is  received  the  name  "Unknown"  is  relumed. 
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hot  tat  Arest  hosts 

Interrogates  tltc  specified  hosts,  or  all  known  hosts  if  none  arc  specified,  with  the 
STATUS  protocol  and  prints  the  results  in  columns  as  a  table. 

chaos: print-conn  conn  Aoptional  (shorn) 

Prints  everything  the  system  knows  about  the  connection.  If  short  is  nil  it  also  prints 
everything  the  system  knows  about  each  queued  input  and  output  packet  on  the 
connection. 

chaos  :pr1nt-pkt  pkt  &optional  (short  nil) 

Prints  everything  the  system  knows  about  the  packet,  except  its  data  field.  If  short  is  t, 
only  the  first  line  of  the  information  is  printed. 

chaos : print-all -pkts  pkt  Aoptional  ( shortx ) 

Calls  chaos:print-pkt  on  pkt  and  all  packets  on  the  threaded  list  emanating  from  it. 

chaos: status 

Prints  the  hardware  status. 

chaos: resat 

Resets  the  hardware  and  software  and  turns  off  the  network. 

chaos :assure-enab1ed 

Turns  on  the  network  if  it  is  not  already  on.  It  is  normally  always  on  unless  you  call  one 
of  these  functions. 


chaos:enab1e 

Resets  the  hardware  and  turns  on  the  network. 

chaos:d1sable 

Resets  the  hardware  and  turns  olF  the  network. 
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11.  The  VAX/VMS  Implementation 


This  describes  the  interface  to  Chaosnet  through  the  routines  in  the  "CHAOS.B32”  BJ.ISS-32 
subroutine  package.  Definitions  of  standard  values  are  in  "NCPDFFS.R32".  Though  it  is  possible 
to  interface  to  the  NCT  at  the  VMS  I/O  level,  it  is  not  recommended  practice.  All  references  to 
Chaosnet  in  this  text  are  with  respect  to  die  subroutine  package,  and  not  VMS  QIO’s. 

A  Chaosnet  connection  is  represented  by  a  one  longword  "channel  number",  which  has  no 
direct  relationship  to  a  VMS  channel  number.  However,  for  every  Chaosnet  channel  currently 
allocated,  there  is  an  associated  VMS  channel  maintained  by  the  subroutine  package. 

All  of  the  routines  described  below  arc  declared  "global". 

1 1 . 1  Opening  and  Closing 
parse_host  (host,  ret-host-num) 

Parses  the  string  pointed  to  by  host  (which  points  to  a  standard  VMS  string  descriptor), 
and  stores  the  resulting  host  number  in  the  word  pointed  to  by  ret-host-num.  Returns  a 
status  code. 

chaos_rf  c  (ret-chan,  host,  contact-name,  wait-time ) 

Opens  a  new  Chaosnet  channel  and  sends  an  RFC.  rel-chan  is  a  longword  to  receive  the 
channel  number,  host  is  a  siring  acceptable  to  parse_host.  contact-name  is  a  pointer  to  a 
string  descriptor,  wait-time  is  either  zero,  which  means  to  wait  indefinitely  for  a  response 
to  the  RFC,  or  a  pointer  to  a  quadword  block  acceptable  to  die  SSETIMR  system  service. 
A  status  code  is  returned,  which  will  be  SS$_TIMEOUT  if  the  routine  times  out. 

chaos_lsn  (ret-chan,  contact-name,  wait-time) 

l.ikc  chaos_rfc,  but  "sends”  a  i.SN  instead  of  an  RFC.  No  host  is  specified. 

chaos_accept  (chan,  window,  rfc-arg,  ret- rfc-arg- size) 

Accepts  an  incoming  RFC.  The  connection  must  be  in  RFC-received  state,  window  is  the 
window  size,  tji-arg  is  an  optional  string  descriptor  which  receives  die  argument  to  the 
RFC.  ret- r/c-arg- size  is  also  optional,  and  gets  the  argument's  length. 

chaos.ans  (chan.  data,  wait-time ) 

Sends  an  ANS  packet  to  the  Chaosnet  channel,  data  points  to  a  string  descriptor,  wait- 
time  is  ignored.  A  status  code  is  returned,  and  if  an  error  occurs,  die  channel  is 
deassigned. 

chaos^c lose  (chan,  reason) 

Closes  the  connection,  and  deassigns  the  channel,  reason  is  a  pointer  to  a  string 
dev  lipior  of  a  string  to  be  included  in  the  CI  S  packet. 
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chaos_asa1gn  ( ret-chan ) 

Assigns  a  Chaosnet  channel,  and  stores  it  in  the  longword  pointed  to  by  ret-chan.  This 
routine  allocates  a  VMS  channel.  A  status  code  is  returned. 

chaos.deasslgn  (chan) 

Given  a  Chaosnet  channel  previously  assigned  by  chaos_ assign,  dcassigns  it  and  the 
associated  VMS  channel. 

11.2  Stream  Input  and  Output 

chaos_1n_char  (chan,  ret-char,  timeout) 

Returns  the  next  character  from  the  channel  in  the  longword  pointed  to  by  ret-char. 
Waits  until  a  character  is  available  or  until  timeout,  whichever  comes  first.  A  status  code 
is  returned. 

chaos_out_char  (chan,  char) 

Outputs  one  character.  Characters  arc  buffered  until  a  packet  fills  up  or  until  the  output 
is  forced  out  by  chaos_force_out.  A  status  code  is  returned. 

chaos.sout  (chan,  string) 

I. ike  repeated  calls  to  chaos_out_char:  sends  string  from  string  descriptor  pointed  to  by 
string. 

chaos_forc«_out  (chan) 

If  doing  serial  output,  and  a  partial  packet  is  buffered,  force  it  to  be  sent 
chaos_f Inlsh  (chan) 

Does  a  chaos_force_out,  then  waits  for  all  packets  to  be  acknowledged  by  the  foreign 
end. 

chaos_eof  (chan) 

Sends  an  HOF  packet  after  forcing  out  any  buffered  output. 

1 1.3  Packet  Input  and  Output 

a11ocato_.pkt  (size,  chan,  rct-pki) 

Allocates  a  packet  suitable  for  chaos_in_pkt  and  chaos_out_pkt.  The  packet  can  hold 
up  to  size  bytes  of  data;  the  number  of  bytes  field  in  the  packet's  header  is  filled  in  front 
size,  rct-pkl  points  to  a  longword  to  receive  a  pointer  to  the  packet.  A  status  code  is 
returned. 

doa11ocate..pkt  (pkt) 

Returns  a  previously  allocated  packet  to  the  free  pool.  A  packet  may  he  reused,  since  the 
I/O  routines  do  not  deallocate  them,  as  long  as  the  I/O  is  being  done  synchronously. 
Returns  a  status  code. 


I  »SK:MOON; Wlltl.R  107 


I5-.II  IN-SI 


Chaosnet 


55 


Cheeking  the  State 


chaos_out_pkt  (chan,  pkt.  efn,  astadr,  astprm) 

Outputs  pkt  to  chan ,  waiting  if  there  is  no  window  room  available,  efn  is  the  event 
channel  to  use  for  waiting,  astadr  and  astprm  are  as  for  VMS  system  services;  an  AST 
address  and  parameter,  respectively,  that  get  signalled  when  the  packet  is  read  by  the 
NCI*.  chaos_out_pkt  returns  as  soon  as  there  is  space  in  the  window,  without  waiting 
for  the  NCR  to  finish  transmitting  the  packet. 

chaos_1n_pkt  (chan,  efn.  pkt,  astadr,  astprm) 

Reads  the  next  input  packet,  whatever  opcode  it  may  be,  from  the  connection,  wailing 
indefinitely  if  there  arc  no  input  packets,  efn  is  the  event  channel  to  wait  on,  and  astadr 
and  astprm  arc  for  an  AS  T  to  be  delivered  when  the  read  completes.  chaos_in_pkt  docs 
not  return  until  the  read  completes.  A  status  code  is  returned. 

1 1.4  Cheeking  the  State 

chaos_xm1t_room  ( chan,  wait ) 

Returns  SS$_NORMAL  if  there  is  room  left  in  the  transmit  window.  Returns  an  error  if 
the  connection  went  into  a  bad  state.  If  wait  is  true,  and  there  is  no  room  left,  then 
chaos_xmit_room  waits  until  room  is  available.  If  there  is  no  room  left  and  wait  is  false, 
it  returns  SS$_EXQUOTA. 

chaos_state  (chan) 

Updates  die  state  of  die  Chaosnet  channel  via  a  request  to  the  NCR.  Returns  a  status 
code.  To  check  die  state  of  the  connection,  first  call  this  routine  then  look  at  chan_state 
in  the  channel  block  described  below. 

chaos_wa1t  (chan,  old-state,  timeout) 

Waits  until  die  channel  goes  out  of  the  specified  state  or  until  timeout  occurs.  Timeout  is 
either  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  SSETIMR.  A 
status  code  is  returned. 

chaos_wa1t_t11  (chan,  stale,  timeout) 

Waits  until  the  channel  goes  into  the  specified  state  or  until  timeout  occurs.  Timeout  is 
either  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  $SET!MR.  A 
status  code  is  returned. 

'Hie  channel  number  is  used  as  an  index  into  the  global  blockvcctor  channel,  defined  in  the 
"CHAOS. 11.12"  file.  Since  lll.ISS-32  docs  not  allow  the  field  definitions  to  be  global,  they  should 
be  copied  into  any  program  that  needs  to  look  inside  the  channel  blockvcctor.  The  most  useful 
fields  arc 

chan_state  One  of  the  state  codes  defined  below. 
chan_sta_txw  The  window  size  in  the  tiansmit  direction. 

chan_sta_rxw  The  window  size  in  the  receive  direction. 

chan_.sta..txwa  The  number  of  packet  slots  available  in  the  transmit  window. 
chan_cla._rxdv  The  number  of  input  packets  available. 
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The  states  arc  as  follows: 

corm_st_closed  (0)  Connection  closed  by  a  CLS  packet. 

conn_st_rfcrcv(1)  RFC  received  by  listening  connection. 

conn_st_rfcsnt  (2)  RFC  sent,  no  response  yet. 

conn_st_open  (3)  Connection  open. 

conn_st_los  (4)  Connection  broken  by  a  LOS  packet. 

conn_st Jncom  (5)  Incomplete  transmission  (no  response  from  foreign  host). 

conn_st_new  (6)  Connection  newly  allocated. 

conn_st_lsn  (7)  Listening  for  an  incoming  RFC. 

conn_st_full  (%0’400')  This  bit  is  set  when  the  transmit  window  is  full.  Usually,  the 

remainder  of  the  state  will  be  conn_st_open. 
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12.  The  Unix  Implementation 

I'he  Unix  implementation  of  Chaosnet  works  on  both  pdpll  Unix  and  VAX  Unix. 

The  network  may  be  accessed  in  four  different  ways.  A  Chaosnet  stream  connection  may  be 
opened  to  a  host  and  a  contact  name,  and  then  standard  Unix  I/O  may  be  done  over  the 
connection.  A  Chaosnet  connection  may  be  accessed  at  the  packet  level  (howeve,  this  is  not  yet 
implemented).  A  Chaosnet  stream  connection  may  be  made  into  a  Unix  tty;  this  is  how  the 
TELNET  server  works.  A  subtree  of  one  Unix  host’s  file  system  may  be  mapped  into  another 
Unix  host’s  file  system,  with  the  intermediate  Chaosnet  invisible  to  programs  operating  on  the 
remote  files. 

You  get  access  to  Chaosnet  by  opening  a  file  pathname  which  includes  a  special  file  whose 
major  device  is  Chaosnet.  The  minor  device  number  of  that  special  file,  together  with  its  name 
and  any  additional  pathname  components  after  it,  are  used  to  determine  the  host,  RFC  contact 
name,  and  RFC  arguments.  Remote  file  access  is  implemented  by  special  files  which  map  into 
the  desired  host  with  contact  name  ftpread  or  ftpwrite.  The  remaining  pathname  after  the  special 
file  is  passed  along  and  used  as  a  pathname  on  the  remote  host. 

The  8-bit  Unix  minor-device  number  is  divided  up  into  several  fields  which  control  details  of 
what  happens  when  you  open  a  Chaosnet  special  file.  The  current  division  is  as  follows: 

bits  6-3  Host  specifier.  Small  numbers  arc  indices  in  a  site-dependent  table  of  hosts  which  are 
particularly  useful  to  connect  to.  This  is  used  primarily  for  the  remote  file-system 
facility.  Otherwise  this  is  one  of: 

015  The  host  number  (in  decimal)  is  read  from  the  name  of  the  special  file. 

016  The  host  number  (in  decimal)  is  read  from  the  next  pathname  component 

after  the  special  file. 

017  Activates  one  of  a  number  of  special  features  selected  by  bits  2-0.  See  below. 

bits  2-0  If  the  host  specifier  is  not  017,  this  is  a  contact  name  specifier.  Small  numbers  are 
indices  in  a  site-dependent  table  of  useful  contact  names.  This  is  used  primarily  for 
the  remote  file-system  facility.  Otherwise  this  is  one  of: 

6  Read  the  contact  name  from  the  name  of  the  special  file. 

7  Use  the  rest  of  the  pathname,  after  the  special  file,  as  the  contact  name  and 
RFC  arguments. 

When  both  the  host  number  and  the  contact  name  are  read  from  the  pathname,  the 
host  number  is  read  first.  Any  character  other  than  the  digits  0  through  9  serves  to 
separate  them. 

If  the  host  specifier  is  017,  this  is  instead  one  of  the  following: 

0  Pick  up  unmatched  incoming  RI  Cs.  Only  one  process  at  a  time,  per  system, 
may  open  this  device.  The  ioctl  operation  chiounext  (see  below)  is  used 
with  this  device. 

I  I  isten  mode.  T  he  rest  of  the  pathname,  alter  the  special  file,  is  the  contact 

name  listened  to.  lias  will  wait  until  an  Kit’  comes  in  m  that  pathname.  A 
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typical  pathname  would  be  "/dev/chlisten/myprotocol". 

2  l.istcn-crror  mode.  Same  as  above,  but  if  there  is  no  pending  RFC  to  the 
contact  mime,  this  will  return  an  error  rather  than  waiting  for  one. 

3  Packet  mode.  This  is  not  implemented  yet. 

bit  7  Specifies  that  this  Chaosnet  connection  should  be  wired  to  a  tty. 

When  a  Chaosnet  connection  is  wired  to  a  Unix  tty,  input  data  from  Chaosnet  appear 
as  keyboard  input  characters  on  that  tty.  Output  typed  on  the  tty  goes  out  on 
Chaosnet  as  data.  When  the  tty  is  hung  up  (logged  out),  the  Chaosnet  connection 
will  be  closed.  I/O  operations  done  to  the  Chaosnet  channel  will  be  done  to  the  tty 
instead,  except  for  the  special  ioctl  operations  given  below. 

When  a  connection  has  been  opened,  the  normal  Unix  I/O  operations  may  be  done  on  it.  8- 

bit  bytes  in  standard  data  packets  (opcode  200)  arc  used.  If  the  Chaosnet  connection  is  not  open, 

the  I/O  operations  will  return  an  error.  When  the  close  operation  is  performed,  if  the  Chaosnet 
connection  is  open  the  standard  F.OF  protocol  will  be  followed  (sec  section  4.4,  page  24). 

The  following  operations  arc  supported  for  the  ioctl  system  call: 

fionread  Returns  the  total  number  of  data  bytes  in  the  available  input  packets.  This  is  the 
number  of  bytes  which  can  be  read  without  waiting. 

chiocflush  Forces  out  buffered  output.  Normally  stream  output  is  held  until  a  packet  is  filled 
up  or  2  seconds  have  elapsed. 

chioerread  Returns  data  from  the  RFC  packet.  This  is  only  valid  on  a  connection  which  was 
created  by  listening  and  which  has  not  yet  been  read  from.  The  source  host  (2 
bytes)  is  returned,  followed  by  a  null-terminated  character  string  which  is  the 
contact  name  and  any  following  arguments. 

chioernext  This  is  only  valid  on  the  unmatchcd-RFC  connection,  and  is  the  only  ioctl 
operation  valid  on  it.  This  waits  until  an  unmatched  RFC  is  present,  and  then 
returns  its  contact-name  and  arguments  as  a  null-terminated  string.  The  system 
unmatchcd-RFC  process  uses  this  to  start  up  server  processes  as  RFC's  come  in. 
(Currently  this  mechanism  is  used  only  for  the  remote  file-system  servers.) 

chioctty  If  the  Chaosnet  connection  is  open,  and  is  not  already  wired  to  a  tty,  this  creates 
a  new  Unix  tty  and  wires  it  to  the  connection. 
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